| Src:blog.briandicroce.com/2008/03/
|
A lot of articles are available explaining TDD for Java and .NET. However I rarely find “good” TDD articles for C++ and C.
James Grenning explains TDD for embedded C++ programmers in a step by step approach in this article
Several articles have been written comparing the heavyweight and the lightweight methods.
However, I found this document to be very comprehensive in comparison.
The document compares the Heavy Weight methods like
Waterfall, UP and Spiral Model with the Light weight methods like
XP, Scrum, FDD, DFDM,etc.
The topic of Generalists Vs Specialists is another eternal debate in the Agile community. Every one in the community has their own opinions. I too have my personal opinion about this topic.
Let me start this discussion with a few definitions.
Put it in a simple way,
| A Specialist is some one who knows a “bit more” about something. In the context of the software world, this something could be Architecture, User Interface Design, Testing, Coding, Business Analysis, etc |
| A Generalist is some one who knows a bit about many things |
The question arises, should we have specialists in the team or generalists in the team. Each of these techniques has its own pros and cons as explained in this article.
My opinion is that, every individual is passionate about something. Some times they get to express it and get opportunity to pursue the same, and many won’t get this chance. People pursuing their passion end up becoming true specialists. However at the end of the day, every one in the software company gets a designation whether they like it or not, and end up becoming specialists.
Many Agile evangelists say specialists are not good. However what they mean is bottlenecks created due to specialization is not good. Bottleneck arises due to demand and supply issue in the organization/project.
Let me give you an example, most of the software companies (that I have seen so far) have limited number of Architects and Database administrators and mostly these roles are shared among various projects. Consider a situation when the Oracle DB admin who is currently been assigned to a new project is at the client site gathering requirements. At the same time, a critical bug was detected in one of the DB modules that he worked on an earlier project and this is a show stopper. This is a challenging situation right ? How can we make use of the DB admin in handing this situation as he is the only one available.
Let us review couple of options on hand
Option 1:
Pull the DB admin for a few weeks from his current assignment and reassign him to the defect until it is fixed. But doing so might make the current client unhappy
Situations like the one mentioned above where the specialists have become bottlenecks have made the Agile thought leaders to encourage generalized specialists.
While I coach teams, I observe that if specialists are going to be shared across projects and by this I know that in the future they would end up becoming bottlenecks.In such instances, I apply what is called “Backup Pattern”. This pattern name is my own invention. While applying this pattern, I start analyzing the skills and passion of various team members and start making each one back up for the other. This provides an opportunity to have backups(in knowledge and skill) and over a period of time, these backups will be in a position to handle most of the specialists tasks. However the same backup personnel would continue to have their own specialization. The team members could volunteer to be backups.
Here is an example of a table showing my backup pattern technique
|
Module Name | Skills/technology | Primary | Backups |
|
Billing | JSP, Java, Hibernate | Rashmi | Rohit, Chandru |
|
Dynamic IP Generation | Java, C++, Tcp/Ip | Jim | Chandru, Rashmi |
| CMTS configuration | WAS, TCP/IP, REST, XML | Chandru | Jim, Rohit |
Above technique has helped me in tackling the issues of specialization. This is not a quick fix, and it takes any where from couple of weeks to months to build a generalized team.
Conclusion
Having an extreme form of all Specialists or Generalists is not healthy for any project. There should be balance between these two types and decision to have generalists or specialists should be based on specific context.
Jeff Patton kept talking about usage of the word Requirements considered harmful during recently concluded Agile Bengaluru conference. When you listen to Jeff from his context and examples, you tend to nod your head in agreement.
Jeff has written a very nice article about the subject and I don’t want to copy/paste the article, and go ahead and read it here.
One of the most popular reports people use to showcase failure of software development is the Standish’s chaos report .
In 1994, Standish reported a shocking 16 percent project success rate, another 53 percent of the projects were challenged,and 31 percent failed outright. Even though the new reports from Standish show better numbers still they cause a lot of heartburn to software companies and investors.
However recently J. Laurenz Eveleens and Chris Verhoef have published a paper in IEEE challenging the numbers stated by Standish report. The major problems in the Standish report seems to be around the way numbers for the Successful and Challenged projects are gathered. According to Eveleens and Verhoef, these Standish figures are:
“misleading, one-sided, pervert the estimation practice,
and result in meaningless figures”
The problem seems to be coming from the way the Successful and Challenged projects are defined. The definition seems to have loop holes due to which many valid projects are not considered leading to wrong result.
You can read the entire IEEE report here 
I attended TOC and JIT session . This session was intended to teach Theory of constraints and in turn identify the bottlenecks in projects. I liked the way the session was structured.
This session also included a small hands on workshop where in the participants form small groups and would pick a project to work on. Within each group, the participants would work on identifying the bottleneck and how throughput could be increased by reducing the cycle time.
I also got a chance to listen to Jeff Patton during one of the breaks.
I had a few Aha moments while listening to Jeff. Here are some points which has put me to ponder for the next few days
1. Requirements are considered to be harmful. Read Jeff’s popular whitepaper here to understand why he says so
2. The projects would always lead to failure as long as we have the You and US mentality between the customer and the software development team.
I also got a chance to meet Bas Vodde, 
who happened to be in Bangalore and just walked in to say hi to Jeff and Dave.
Bas and Craig Larman (my Guru) have written 
various books and white papers. I highly recommend the recently released book Scaling Lean and Agile. 
Just returned home from the ASCI Agile Bengaluru 2010 session. The event was well planned and organized.
The session started with David Hussman’s Discovery and Delivery - Redesigning Agility.
I realized that every presentation by Jeff Patton and Dave revolved around discovery and Delivery.
Next session that I attended was by Jeff Patton. He is a very knowledgeable guy and I enjoyed his session on User Story mapping. More info about this technique can be found here.
Here is the gist of the session
Most of the time people relate Features to User stories, which is a big misunderstanding. People with this misunderstanding, and continuing to gather requirements in the name of user stories would end up creating bucket of features list.
One of the key point I learnt from Jeff’s session on User Story mapping was the importance of the good facilitator. During the user story mapping workshop, he was able to gather the stories by asking the right set of questions.
Don’t get bogged down by the formula
Nowadays it is increasingly becoming popular to follow the user story template
As a [role], I can [feature] so that [reason]
However, Jeff made it clear that there is no harm in using the above template however don’t get bogged down with this formula. Understand the intent behind the above template and create the stories in your way.
Jeff also touched upon the importance of Personas.
Blogger Labels: Agile,Bengaluru,ASCI,Delivery,presentation,Jeff,Patton,Dave,User,Story,info,technique,Here,gist,Most,Features,People,requirements,bucket,importance,facilitator,workshop,formula,Nowadays,template,role,Understand,PersonasCame across this new Open Source project management tool called Express. This tool seems to be still in beta development.
More details below,
Express is an Agile project management tool. The web application is written using Flex while server-side component is a Spring based Java EE application.
You can download the same from here
Following are some of the screen shots of the application
Backlog management screen
Virtual wall
Every Agile project has some impediment in one form or the other.
We could list out many more...
I came across this article which lists 100 impediments that is constantly seen on Agile projects.
This website classifies various impediments into categories.
Whenever some one makes a promise, the cost of apologizing begin to grow. Whenever one feels that promise cannot be kept, the cost of recommitment starts to grow. The cost depends on the stage at which recommitment is done. If the apology and the recommitment is done at an early stage, the cost is going to be less. If not, it is going to grow exponentially inflicting economic and emotional damages to the people involved.
Consider a situation where a Project Manager(PM) of a software company promises to deliver a component on a certain date to the customer. During the development, if something breaks down(and the remedy to this problem is beyond the control of the PM) then the PM has two options in front of him/her.
With the option 1 above, customer may or may not become happy to hear about the problem. Some customers are happy to see the PM bringing the problem to their notice at an early stage. This in turn provides them an opportunity to make alternate arrangements in the face of this problem. However, a few customers could get upset as many of them don’t like to hear about the problems.
Option 2 is typically applied when there is sufficient time for delivery. Since the customer is not aware of the problem, the PM could assume that some how he/she would take help from somewhere and would fix the problem before customer notices it. Since customer is not aware of the problem and sufficient time is left, there is no pressure to fix the problem immediately.
Option 2 mentality is typically seen in Waterfall development teams.
As per Fred Kofman, most of the teams who follow Option 2 fail in some way or the other. He continues to say that,
Unfortunately these hopes do not always become realities. The work falls further and further behind, while the creditor is in the dark, unable to hedge against a risk he knows nothing about.
Fred calls the hope of people with Option 2 thinking as Self serving rationalization.
How does this relate to Agile ?
The Agile practices are structured in such a way that, opportunities are provided on a daily basis to bring up the issues upfront. This could be either through the Scrum meetings, reviews, or retrospectives. This is nothing but exercising Option 1 mentioned above. This in turn removes any hopes fulfilling self serving rationalization and in turn reducing the cost of apologizing and recommitment.
Recently I watched this informative video by Tim Lister in which he speaks about Agile project leadership. I would highly recommend this video for all Agile practitioners.
As we know, Tim is the author of the two greatest books of this decade. They are
I made some quick notes for myself while watching this video, and thought would share the same here.
1. Process is something you do naturally. Real process is something you do when you are under pressure.
2. A Leader is someone, who by dint of words and or deeds,influences the behavior of others
3. Great Projects have emotions
4. Software development could be compared to an orchestra. Both Orchestra and Software development involves different types of people, and even if one or two don’t perform well, everything goes for a toss.
5. It is really hard to hate when you know the name
6. Cross Pollination is critical. Ex: Americans and Canadian. Even though they speak the same language, still they feel different.
7. Question: How do you keep the teams motivated ?
Tim : Teams thrive on Interesting Problems. Teams cannot be motivated by giving more salary.
(Rephrased in my own words) For ex: if some one is given 2000 USD rise, the developers won’t jump in and say that from today onwards I am going to be more productive. Maximum thing they would do is call their family and take them for dinner and forget it as though nothing has happened.
8. Every leader has to groom another great leader
9. in Hitachi, every project team has to try something different. The management rejects if the project planning is done in a way similar to others.
10. CMM is score card to rate the process
11. If you are just doing what Agile methods say, you are already at CMM level 3
12. Hockey is Un-Choreographed Ballet Dance. This could be compared to Agile. While on the field the players have to think about various situations and make dynamic decision. The coach cannot guide each and every move of the players.
The Agile Software Community of India (ASCI) is organizing the 2nd Annual Agile Conference in Bengaluru on 22nd and 23rd Jan 2010 named Agile Bengaluru 2010.
For the first time in India, we’ll have 4 Gordon Pask Award Winners at a single conference:
The conference theme this year is “Post-Modern Agile - Be done with the Dogma“. The conference is really targeted at Agile practitioners, who want to explore ideas beyond the basic Agile stuff.
Also this year, for the first time, we are hosting the World-famous Programming with the Stars contest during the conference.
After the standard proposal submission and review process we have the final conference program published - http://www.agileindia.org/agilebengaluru2010/agile-bengaluru-2010-program.htm.
If you are interested in participating in the conference, hurry up and register for the conference here: http://www.agileindia.org/agilebengaluru2010/agile-bengaluru-2010-registration.htm We have limited 125 seats total.
Also for those who cannot attend the Bengaluru conference, don’t worry. We have another conference in Mumbai. Check out: Agile Mumbai 2010 Conference.
Please use the #agile_bengaluru_2010 Twitter tag.
If you want to make enemies, try to change something - Woodrow T. Wilson
Transitioning from waterfall to Agile is not only a big change but also a change that needs to happen at an organizational level. Leaders leading such changes need to have a clear vision about the end goal and need to effectively communicate the vision to all. Lack of clarity in the vision and communication leads to creating more enemies than friends.
A CEO of an organization could command all projects to start practicing Agile immediately. Most of the employees have no choice but to follow the command. However employees who are not sold to this idea won’t be doing the work by putting their heart and soul in it. This change will die down over a period of time and such organizations will never be able to bring a new process change like Agile.
In order to effectively bring Agile into an organization, one has to identify the areas of resistance and meticulously handle them.
Always remember
Resistance creates Persistence
Here are some of the tried and tested techniques for bringing organizational changes :
Share the big picture with the employees Share the reason for the change and its benefits for the organization Trust the team implementing the change Do an incremental change rather than big bang approach Provide the necessary support for implementing change (logistics, training, etc)
Understand the groups who could resist the new changes and tackle them
Some great articles have been written by various thought leaders about bringing organizational change. Here are some of them:
Leaders do mistakes while bringing process change (like Agile) into organization. This article lists the common mistakes that leaders do while implementing the change.
Summary
An organization deciding to embrace Agile shouldn’t rush with the big bang approach. One needs to have patience and use the incremental approach.
My experience in helping organizations in transitioning from waterfall to Agile says, it could take any where from couple of months to a year or two for a complete transition.
Every organization and every project has some grapevine running in the inner circle. When I say Inner circle,
it is the closed group of people who trust each other.
For ex: In a typical software project, a manager(PM) with command and control attitude, would encourage creation of inner circle with project team members, whose opinions are being ignored by the PM. This inner circle group excludes the manager. This group in turn talk among themselves and share their agonies without the knowledge of the manager.
Above example of team member inner circle group, can be extrapolated at an organizational level with inner circle being the employee group excluding the management of the company.
The inner circle groups mentioned in the above examples are harmful for the project and the organization. They get created as they don’t have any venue to express their bottled up emotions/thoughts/opinions. This in turn leads to a lot of negativity. This negativity needs to be conquered sooner than later. Here is a good article, which provides techniques to conquer such negativity.
One of the ways to conquer the negativity is to provide a platform for the employees to express their thoughts/opinions/emotions. In Agile projects, retrospectives provides such a venue. This in turn leads to healthier project and teams in a longer term.
“Iteration” is commonly used to term in all Incremental and Iterative development methods.
However the word “Sprint”, which has similar meaning to iteration was coined in the Scrum method. Mostly the Scrum practitioners use the word Sprint. Even though many people use the word Sprint and Iteration interchangeably, there is a notable difference between the two.
Sprint as defined in pure Scrum has the duration 30 calendar days. However Iteration length could be anything as defined by the team.
Bringing change is not easy, and people resist changes. Top ten reasons why people resist changes can be found here. Nowadays new processes and technologies keep getting invented everyday and the employees need to be up-to date with it to be competitive.
Introducing the new concepts is not easy. Thought leaders have come up with several patterns too to introduce changes in the organization. However recently I came across this article Testing on Toilet, which talks about the innovative way being used in Google to teach their employees testing and bringing new change. As per the author,
A regular weekly(ish) tip posted in toilet cubicles and above urinals. Short enough to be read whilst doing your business
Even though the above method looks odd and radical, trust me at the end of the day, developers would definitely learn something good and remember it for a long time.
Here is one of the actual pictures taken in the Google toilet giving some tip about testing certification
Suddenly I am seeing a spurt in activities around Agile certifications. Scrum Alliance is working seriously with various thought leaders in coming out with new certification criteria. There is another organization World Agile Qualifications Board(WAQB) coming up new Agile certifications.
Hope all these people come together and have one certification at some point of time in the future.
Scrum being the most popular Agile methods, a lot of new Scrum users either are getting distorted definition of many Scrum terms or have total misunderstanding of the terminologies.
To avoid such misunderstandings, Scrum Alliance has glossary of 39 key Scrum terms
Following questions are frequently asked by the novice Scrum teams. I will keep updating these questions and answers as and when I get it.
1. Can we have single Scrum Master(SM) for multiple projects ?
Answer: It is recommended to have a dedicated Scrum Master for each project. Diluting this could also dilute the effectiveness
2. Can Scrum Master be a Product Owner ?
Answer: Scrum Master should never be a product Owner.
3. Can Scrum Master be technical and can SM help the team if they are stuck with technical issues ?
Answer: It does not matter if the SM is coming from technical background or management. However if SM is technical, he/she should be careful enough not to dilute the SMs responsibilities in the process of helping the team with technology stuff.
4. During the Scrum Meeting, my colleague talked about an impediment and I had the answer. However, can I answer it immediately and it won’t take more than 1 minute ?
Answer: Don’t diverge from the recommended rules around Scrum Meeting. Any discussion should happen outside the Scrum Meeting. Even though your answer takes only one minute, some one else could also jump in saying even he/she needs a chance to answer another question. This leads to chaos and could stretch Scrum Meeting beyond recommended limit of 15 – 20 minutes. My recommendation is to follow the rules by the book until every one gains experience.
5. I just need another 4 hours to complete my task and the iteration is coming to an end, can I stretch the Iteration/Sprint duration ?
Answer: No. Iterations are time boxed.
6. When people say Sprint duration is 30 days, is it working days ?
Answer: Sprint duration of 30 days means 30 calendar days.
7. The team has completed all the tasks before the sprint ends, what should they do now ?
Answer: The team can approach the product owner and request for additional items from the PB.
8. Is it mandatory for the team to follow the Idealized line in the burn down charts ?
Answer: Idealized(A.K.A Ideal) line provides just a point of reference.
9. Can I work on the undone tasks in the next iteration ?
Answer: Undone tasks would go back to Product Backlog and Product Owner would make a call on the set of requirements for the next iteration with due feedback from the team.
10. Should I use Iteration or Sprint ?
Answer: All sprints are iterations but not all iterations are Sprints. Sprint is the terminology coined by the Scrum co-founders to define an iteration.
========================================
P.S: If you are aware of more questions and answers, feel free to send me and I would post it here.
A team adopting Agile method for the first time tends to do many mistakes during the initial days. One of the common mistakes is about trying to do accurate estimation. During the Iteration Planning Meeting(IPM) of the first iteration, the team does not know their velocity and tends to spend time trying to come up with “accurate” estimates or estimates with additional unscientific buffers. They tend to spend too much effort detailing out tasks and estimate them.
Agile methods discourages teams spending too much of effort on reaching perfection in one go, especially around estimations. It recommends teams to apply the empirical control model by frequently inspecting the estimations and adapting them.It recommends to go with daily re-estimation technique.
Daily re-estimation
Agile methods recommend that
Subsequent Iterations
Right from the first iteration, the team must track couple of key parameters, For Ex:
Once the team gets to know their velocity, the future iterations could be estimated and planned in a better way.
Conclusion
