Release plan checklist

When I build release plans, or even look at release plans of other projects, I end up running through a checklist of things in my mind, to determine if it is good enough. If you are an Agile PM trying to build a plan, this could be useful for you.

Iterations	Is the length of the iteration enough to be able to complete a medium size story within it ? Do the number of iterations fit well within the acceptable timeline ? Can we assume a production quality build after every iteration ?
Estimation	Are the stories sized relatively ? Does the team understand the estimation unit across all roles ?
Velocity	Is the planned velocity, the average velocity of last 3 iterations ? If its a new project, are we planning based on a raw velocity exercise ? Are team members across roles in planning the velocity ?
Resource ramp up	Is there time  factored in  for new people to ramp up on the team ?
Ordering of stories	Are the stories ordered around the critical path functionality ? (Always remember the critical path determines the schedule) Are the higher priority stories slotted for earlier iterations ? Are the stories ordered so that they meet any functional or technical dependencies?
Negotiable Scope	Are there some “nice to have” stories in the plan which can be later negotiated if need be to bring the project on track ?
Spikes / Proof of Concepts	For technical unknowns, are there spike stories which allow the team to explore technical solutions ?
Non functional requirements	Is there clarity on requirements for Performance, Security, Scalability and how they are going to be addressed ?
Functional Automation	Will developers do functional automation as a part of a story or this will be done as a part of QA ?
Regression/Stabilization	Is there a need for a separate regression/stabilization iteration once the development is complete ?
User Acceptance Testing	How much time is required to UAT the set of stories the team will deliver ?
Risks	Does the team understand how much risk is there in the plan ? Are these risks shared with the customer ?

Track all development work as story cards

Managers new to agile teams are often in a dilemma about what work should be written on a Story Card and what should be tracked in your favourite project management tool. Since the smallest unit of work is widely known as a User Story, people often are confused how to track all other work that the team has to do.

In short, all development work done by the team should be written on Story Cards (as above). Majority of these will be User Stories but there can also be several other categories such as

• Infrastructure/Technical Stories – Tasks such as setting up continuous integration environments, developer machines etc…
• Spikes – Proof of concepts / Prototypes
• Performance Stories – Stories involving performance testing / tuning etc…
• Technical Debt – project’s technical debt.

If you are using an Agile project management tool (Eg: Mingle, Greenhopper etc…) it should allow you to create different card types and set workflows based on them.

The important aspect is that every bit of work which is done by a development team should be part of a card which is tracked.

All above story types should be estimated, prioritized, planned and tracked in the same way as one does with user stories. The technical stories however need not be signed off by business stakeholders. It would be of more interest to a technical stakeholder within the project team to sign off such stories.

Questioning Velocity

What is velocity in an Agile project ?

Velocity is the total number of story points of stories which were completed in an iteration. Stories should be DONE by the team’s definition of DONE.

How do we account for partially completed stories in an iteration ?

In an iteration there will be stories which are partially completed. These stories should not be considered in calculating velocity for that iteration based on partial credit. These stories should be accounted in the velocity for the iteration in which they are actually DONE.

How does one plan velocity when starting a new project ?

When starting a new project, since there is no previous velocity to go by, there are a couple of options one can use

a. Ensure that at least a developer pair is available for a week to do a couple of Small/Medium stories from the release scope based on the technology stack proposed. A QA can then decide roughly how complex it is to test the story manually and also write an automation script for it, This should give the team some confidence on the technology proposed and also a rough likelihood of stories which  can be completed within a week.

b. Do  a raw velocity exercise. In a raw velocity exercise the team decides how many stories can it finish in an iteration period. This is done by repeatedly picking different sample sets of  already sized stories which can be done within an iteration period. The total points across different picks are averaged and that is taken as the velocity the team will achieve each iteration. (For example if the result of 3 picks was 6,8 and 10 points for a 2 week iteration then (10+8+6)/3 = 8 points is the raw velocity for the team for 2 weeks. A schedule can then be laid out assuming the team finishes 8 points in a 2 week iteration.)

Either a. or b. or both can be done before planning velocity for a release, but all of these will only provide an indicator of the team’s velocity but the actual velocity of the team will only stabilize over time as the team learns more about the domain and the technology of the project.

Should we also measure velocity in parts such as developer velocity , QA velocity etc… ?

Velocity should always be measured by the definition of DONE of a story. Measuring velocity in parts is again saying that a story is partially done, which in itself does not have any meaning. In an ideal world a story is done when it is in production, but for accounting velocity, once should at least account for stories only when they are tested, showcased and accepted by the customer in a production like environment

Should we plan the same velocity even if the team is ramping up with new people ?

During the release planning exercise, one should also arrive at a rough staffing plan. This should show addition of people (Developers, BAs, QAs) staggered across various iterations in  a project.  Based on this, a ramp up velocity should be planned as the new people joining the team will have a learning curve ahead of them before they start contributing as effectively as the existing team members.

As an example if 1 pair of developers were doing 5 points in an iteration, then adding a new pair of developers to the team will not double the velocity immediately to 10 points, as the new developers will be learning more about the project in the first few iterations. So a staggered velocity of 5,7,10 for the 3 iterations maybe more realistic.

What should be done if the team does not achieve the planned velocity for the iteration ?

Before making any decision to change the planned velocity, one needs to understand the root cause of the problem. If the team set out to achieve 10 points in an iteration and could do only 6 points, what was the actual reason for not completing 4 more points. Was it because of poorly analysed stories, technical debt in a certain area, new technology/framework usage etc… If the root cause can be fixed in the subsequent iteration, such as adding an experienced business analyst to work with the customer closely to provide well analysed stories, the team can still set out to achieve the planned velocity in the next iteration.

However, if the team is consistently able to achieve only 6 points as an average over the last 3 iterations after exploring and eliminating all possible root causes, then it is sufficient to say that the average velocity of the team is 6 points. In this scenario, the first thing is to let the customers know the current team’s velocity, and make them understand the reasons behind it. The next thing is to look at project variables such as Scope, Time & Cost along with the Trade off Sliders and see which of the variables can be compromised without conflicting interest of project stakeholders. An example could be reducing the scope of the release by dropping a few nice to have stories if the trade off sliders indicated scope being a lesser priority than being on time and within budget.

Do technical/infrastructure stories and spikes account for velocity in an iteration ?

Especially during the start of a new project, there will be activities such as setting up basic infrastructure for the project such as build scripts, continuous integration, environments etc… There will also be spike stories which need to be played to understand other frameworks and systems we need to work with. Since the team is spending effort in these stories and tasks, these should be accounted for in the velocity of an iteration. Hence any technical story or a spike should be estimated as all the other stories in the release and planned in the same manner.

The team also fixes defects in an iteration. How do we account for them in velocity ?

Defects can broadly be of 2 categories in an iteration.

The first category is of story defects which are defects on stories which have not yet been signed off by the QA team during an iteration. In this case, once the defects are fixed the story will get signed off by QAs and hence the story points associated with the story will account for the velocity.

The second category of defects will be because the application has regressed over a period of time and these defects are part of stories which were done in earlier iterations by the team. This can happen because of a missing safety net such as a unit or an acceptance test when the story was completed earlier. The team will have to spend effort fixing these defects but they do not account for velocity separately. If a team was doing 10 points in an iteration, having 4 such defects might let the team do only 8 points in that iteration. Hence the velocity is a clear indicator that regression defects are slowing down the team’s progress. Addressing the technical debt of test coverage around that area will ensure such defects are minimised.

Questioning Story Points

What is a Story Point ?

A Story Point is a subjective unit of estimation used by Agile teams to estimate User Stories.

What does a Story Point represent ?

Story points represent the amount of effort required to implement a user story. Some Agilists argue that it is a measure of complexity, but that is only true if the complexity or risk involved in implementing a user story translates into the effort involved in implementing it.

Here is an article by Mike Cohn that explains this in detail. Do make sure you read the comments.

What is included within a Story Point estimate ?

A story point estimate should include the amount of effort required to get the story done. The definition of done here should ideally involve development effort as well as testing effort required to implement a story.Once the user story is implemented, it should be usable in a production like environment.

Why are Story Points better than estimating in hours or days ?

Story point estimation is done using relative sizing by comparing one story with a sample set of already sized stories. Relative sizing across stories tends to be much more accurate over a larger sample, than trying to estimate each individual story for the effort involved.

A simple analogy is that it is much easier to say that Delhi to Bangalore is probably twice the distance of Mumbai to Bangalore than actually trying to put a number such as 2061 kms against Delhi – Bangalore.

Teams are hence able to estimate much more quickly without spending too much time in nailing down the exact number of hours or days required to finish a user story.

How do we estimate in points ?

The most common way of estimating stories is to categorize them into 1,2,4,8,16 points and so on. Some teams are more comfortable with using a Fibonacci series of 1,2,3,5,8 as the point scale. Once the stories are laid out in index cards, the team can start with sizing the first card which the team feels is of a smaller complexity.

As an example , a team might pick the Login user story and call it a 2 point story and subsequently pick a customer search story and call it a 4 point story as it probably involves double the effort to implement than the earlier login story. This exercise is continued till all stories have a story point attached to them.

Who should be involved in Story Point estimation ?

The team which is responsible for getting a story done should ideally be part of the estimation. If the team has QAs to test stories and do test automation, they should also be part of the estimation exercise along with the developers.

The QAs should be able to call out if story has less development effort and more testing effort involved. For example building a customer search screen might be a 4 point story, supporting it on 2 new browsers might be a 1 point development effort but a lot more from a testing perspective. In this scenario QAs who are part of the estimation exercise should call this out and size the story to reflect the adequate testing effort which in this example might be 2 points.

How do we convert Story Points into hours or days ?

This should not be done at a story point level. Story Points go hand in hand with Velocity and hence Velocity at the end of every iteration should be measured in the number of Story Points done by the team.

Should we do a best, likely , worst case estimate even when we are estimating in points ?

Giving 3 estimates for a User story can still be done using story points by just providing 3 different points for the best, likely and worst case scenarios. This is quite effective when estimating a large sample set of stories probably during the first release of the project where little code has been written.

Doing this provides a range across which estimates may vary depending on outcomes of certain assumptions which the team has made. For example a best case estimate for the Login story could e 2 points assuming integration with a local LDAP server, but if that assumption changes to a 3rd party provider integration the worst case could be 8 points.

How do we plan/schedule a project using Story Points ?

To convert story points into schedule, the team needs to calculate their velocity in terms of number of points the team can deliver in an iteration. This is typically done using yesterdays weather by averaging the velocity achieved by the team in last 3 iterations.

If the team is starting afresh , then a raw velocity exercise should be done. In a raw velocity exercise , the team decides how many stories can it finish in an iteration period. This is done by repeatedly picking different sample sets of already sized stories which can be done within an iteration period. The total points across different picks are averaged and that is taken as the velocity the team will achieve each iteration.

For example if the result of 3 picks was 6,8 and 10 points for a 2 week iteration then (10+8+6)/3 = 8 points is the raw velocity for the team for 2 weeks. A schedule can then be laid out assuming the team finishes 8 points in a 2 week iteration.

Can Story Points be standardized across various teams ?

Different teams will end up having a different measure of Story Point depending on the the sample set of stories they are sizing. Unless they are building the same system the amount of effort required to finish a 1 point story by team A will be different to the amount of effort required by team B to finish a 1 point story in their system. And this difference will ultimately show up in velocity of team A and team B.

If there is a large program of work which is split into multiple teams building certain areas of a large system, it is quite tempting to attempt to standardize the point scale across these teams. This again defeats the purpose of estimating using story points and it being a unit of measure subjective to a team.

How do we estimate spike stories in points ?

Spike stories are stories which a team plays to better understand how to implement a particular feature. It can also be used as a proof of concept. Since in a spike very little is known about the amount of effort involved, it is typically time boxed with an outcome that the team can agree upon. This can be approximately converted into points by looking at the velocity trend. For example, if it is required to plan a week long spike, and the velocity of the team has been 16 points, then we can attach 8 points against the spike story.

Is there a way we can calculate cost per point ?

Cost per point will typically be ( Cost of an iteration ) / (Velocity per iteration (in points) ) / . In cases where there is an additional stabilization sprint or regression iteration, the cost of that iteration should also be included to calculate the cost per point.

Are story points an excuse for teams not being able to estimate correctly in days/hours?

It is not an excuse but a reality that it is a waste to attempt arriving at an accurate number in days or hours for a User Story. The amount of effort and time required to arrive at such a number trades off against the benefits of estimating in days/hours.

Moreover estimating in days/hours often puts pressure on the team to deliver within the stipulated number of days and the team ends up burning themselves to meet such false commitments. This results in the team never reaching a sustainable pace over a period of time.

Do Story Points relate to Business Value ?

Story points are an internal measure of effort involved in implementing a user story. It does not, in any way, reflect the amount of business value a user story provides. There might be cases where 1 point story might provide a lot of business value versus a 4 point story in the same system. Business value is best left for the product owner and business stakeholders to be able to determine.

Here is an article which talks about measuring business value in much more detail.

How do we know if the team is getting better at estimation when it is estimating in points ?

It is a popular belief that if the team were to estimate in ideal days, then it is much easier to track if the estimation is good , by checking the actual days elapsed on a story and the progress against it. This is however counter productive as the team spends hours to estimate few stories to arrive at the magic number of days before being pressurized to deliver on that magic number.

When a team is relatively sizing stories in points, a trend slowly starts emerging where similar sized stories start showing similar time to implement them. If there is a bad estimate , then that bubbles up automatically as an exception

Should developers change their story point estimation as they learn more about the system they are building ?

If a story A was classified in the 2 points bucket, a similar story B coming in months later should be classified in the same bucket. If the team has learnt more about implementing them between when story A and story B were played, this will show up as an increase in velocity of the team.

It is better to setup a relative sizing triangulation board for the team which has placeholder stories from the initial estimation session, so that later on the team can relate to it while sizing a new story.

Increasing predictability by moving the definition of DONE

The definition of DONE for an agile project team is quite important as that determines which stories are actually completed and can be accounted for in velocity for the iteration.

A team usually starts by treating a product owner’s approval after a showcase/UAT of a story as DONE. Though this sounds simple, it can get dirty when environments are not available to showcase on, or when the product owner is not fully engaged with the team. In such a scenario it is very tempting to go down the path of having Dev Complete or Testing Complete as DONE and go on claiming velocity without fixing the root cause.

Velocity is a measure of predictability and by moving the definition of DONE to the left side of the story wall reduces a teams ability to predict how much work they can chew. A team should always strive towards moving this definition to the rightmost lane of the story wall.

Definition of DONE	What you cannot predict ?
Development Complete	Bugs in testing, Bugs in testing by a Product Owner, Deployment issues in production
Testing Complete	Bugs in testing by a Product Owner, Deployment issues in production
UAT Complete	Deployment issues in production
Deployed	Really DONE – Its in Production !

Maintaining a predictable velocity is important to plan a project better long term. As a project manager of an Agile project one should strive towards moving to a "DONE = Deployed to Production" state with each iteration.

A nice side effect which starts to emerge is a reduced waste such as manual deployment activities which can be automated when one starts to focus on moving stories to the rightmost end of the story wall before accounting them in velocity.

No fluff, just releases into production every 2 weeks

My current project is a small Ruby on Rails application which is part of a larger web portal. The fun part is that we are releasing new features into production every 2 weeks. Each new feature adds a lot of business value to end users as well as the business stakeholders.

The business we cater to is evolving at a fast pace, and as an IT team, this quicker delivery service provides them a  lot of flexibility. The dynamic nature of business means that we never have requirements which are frozen, even for a period of 2 weeks. This also means that the IT team needs to respond to the changing requirements very quickly.

An important practice that has helped us, is to deploy into an exact production replica UAT environment 3-4 times a day so that the latest application is always available for the business to provide feedback. The business is exactly in the same situation as Jeff Patton describes here http://www.agileproductdesign.com/blog/dont_know_what_i_want.html by not knowing exactly what they want, and the rapid feedback cycle on the latest developed application allows us to build the feature right for them.

Most of our deployment scripts to UAT and Production are automated to an extent that it is a one click deployment to production. Not only does it make deployment simple, but also rollback simpler in case of an unexpected error.

We are still managing without creating a production branch. Having a production quality application in the UAT environment almost everyday helps us in applying an urgent bug fix if required and deploying it to production the very next day. Having a good version control like Mercurial is useful to keep half done stories outside the production build in such cases.

Lastly we do not spend time doing estimation on stories. We tend to keep the backlog to a minimum and try to move almost all the stories in progress to production every 2 weeks.

How much should you plan in Agile ?

Planning in Agile varies a lot given the kind of project, the size of the team, the dependencies and commitments to stakeholders. Because of this, Agilists around the world hold varied opinions on how much one should plan in an Agile project.

There is no prescriptive answer to that question, however, the level of detail one can go to before putting together a project plan can be decided based on the given circumstances.

Minimal planning is working out of a prioritized backlog of stories

Prioritizing stories based on business value is almost always the first step in plannning. Once we have a prioritized product backlog the team can start working on the highest priority story from the top of the stack.

This mode of working is particularly useful when there are no strict timeline commitments for the stories to be released to production. This might happen in scenarios where it is a small application and the product owner is comfortable with doing a release when he feels that enough is built in the application to be seen by the users. This can also happen when the team is working on enhancements or bugs post a production release, and is waiting for business to decide the next milestone. This works well in small teams of 2-3 pairs.

Planning a Single Sprint

The next level of detail is planning atleast for a Sprint(2-4 weeks). A Sprint backlog (or an Iteration Plan) helps in creating visbility for a very limited period of time which is useful both for the Product Owner as well as the team. An example of a Sprint commitment to a product owner can be delivering 20 points of work from the product backlog which translated to 5-6 User Stories.

Planning only for one Sprint is useful when the Product Owner does not have longer term visibility on features/stories for the team. This might also happen when we are waiting things like user feedback etc... to determine the next set of stories to be played.

Doing Release Planning across Sprints

A longer term view of the feature pipeline can help the team build an exhaustive release plan across Sprints. This can be done by slotting stories in an Iteration and even looking at paralellization of stories between development pairs. This sort of activity is best done by sticking stories putting up all the stories on a release wall and collaboratively building the release plan on it.

The number of stories slotted within an iteration is guided by the velocity the team thinks it can achieve. This release plan gives a planned burn down of the scope which the team sets out to achieve and acts as a great metric for the team to measure "How are we doing ? "

Doing Release Planning for multiple work streams in a program of work

Doing a release plan for multiple workstreams in a program is extremely helpful to identify dependencies across streams. It also helps rollup a program level burn up across all teams in the entire program of work. This is particularly useful when running a large program with multiple work streams where tracking progress and dependencies on a day to day basis becomes difficult. Doing a little more of upfront planning helps in the long run.

Rescuing Agile projects in distress

With the current trend of large organizations struggling to adopt flavors of Agile, one often encounters Agile teams in distress.These teams find it difficult to work in a sustainable pace and deliver predictable results to their customers. Bringing such teams back on track is an interesting challenge faced by Agile practitioners all over the industry. Being an Agile Coach in such an environment can be quite overwhelming and it is important to iterate through the steps intended to bring the project and team back on track.

Definition of DONE

The team needs to have a clear definition of DONE for stories in the project. A story is DONE and accounted for, in the velocity of an Iteration, only if it is accepted by customer. In teams which are plagued with various issues, this definition of DONE often gets compromised. Teams tend to call "Development Complete" or "QA Accepted" as DONE. Both of these only allow sub optimization of the value stream and it is better for the team to move towards "Customer Acceptance" as DONE, as soon as they can.

Minimize work in progress

An incremental backlog of "In Progress" stories starts getting built, when a team does not achieve the same velocity as what was being planned for. Before you know this backlog becomes huge and unmanageable. A lot of stories often tend to get stuck in the QA phase with a lot of bugs. If stories do not follow INVEST principle, QAs also.find it difficult to test these stories. Stories might get stuck in development for a long time, if developers on the team are busy cleaning technical debt as a part of a functional story.

It is extremely important to stop the line and fix some of these problems, by doing all it takes to get the stories "In progress" to "Customer Acceptance" before signing up for new work. If you have a huge QA backlog, try and understand the root cause of it. Is it because QAs are not getting good builds to test on ? Or is it really a capacity issue ?

Bring in Scope Control

Controlling changes in scope at all times is important to ensure that the team is working on stories which provide the maximum business value to customers. Sometimes teams struggle with this because they are dealing with product owners who defer any commitment, either for signing off story narratives, or accepting a story in a build. Product Owners (Customers) should be made to understand the scope of each and every user story during release and iteration planning.

In a situation where there is lot of change in requirements, introduce a release level baseline of stories. Create a light weight change control with a group of people who approve any changes to the release baseline. This board should include at least one stakeholder who is responsible for the cost/budget of the project, along with a lead business analyst from the team. This ensures changes are well accommodated into the release plan before they are developed.


Prioritize bug fixes

A common smell with too many bugs is prioritization. Almost every bugs ends up being critical, and hence triaging bugs with customers on a regular basis becomes essential. This ensures that the team is fixing only bugs which add maximum business value considering limited development capacity. It is also important that enhancements are explicitly called out and not buried as bugs. This should also happen during the daily triage of bugs.

(Fixing the Criticals and Highs is more important)

There is a good chance that if a team is running behind schedule then there might be a lot of bugs being introduced in the system. Analysis of these bugs more closely should yield patterns such as fragile areas in the codebase, lack of unit tests, tricky UI issues etc. which could be primary causes of these bugs. It is important that these causes are talked about regularly in standups and unit tests written to cover the issues wherever necessary. Fragile areas also highlight technical debt in the codebase which should be prioritized and cleaned up.



Prioritizing technical debt in the codebase

Technical debt slowly starts getting accumulated when refactoring areas of the code is deferred due to project pressure to deliver functional stories. If this continues for longer, it begins to hurt the team by manifesting itself in the form of bugs and longer development times for stories. It is essential to start prioritizing technical debt and playing the higher value tasks every iteration. Technical leads within the team can help with this prioritization and bring to the table technical stories that can be played during the Iteration planning meeting. Awareness about this technical debt needs to be created by writing on big visible charts, talking about it in standups, and by even conducting group refactoring sessions.


Regular Status Reporting

When a project is in distress, everyone is concerned and wants to know where the project stands almost everyday. It is vital to provide this level of visibility to customers, especially when they are paying for it. One needs to constantly provide information of the risks and issues impeding the project and the way the team proposes to deal with it. If the team's velocity is low for an iteration, it is important for the customers also to understand the reasons behind it. This ensures that the customers and the delivery team work together as a unit towards a common goal,and eliminates any uncecessary friction.


Continous Integration and Automation

It becomes all the more important to keep the Continuous Integration system stable and running when a project is struggling to be on schedule. Discipline around not checking in on a broken build and periodically cleaning up the build files to improve build times go a long way in eliminating delays for the team.

It is also important to run a suite of Automated functional tests that ensure that the application is not broken with any checkin. A small set of Smoke tests can be identified by the team that can cover the breadth of the application. An exhaustive suite of regression tests can also be run periodically to minimize manual regression efforts.



It is always the people

It is always the people in the team who make it work. You always need a highly motivated set of individuals with a strong resolve to pull things through difficult times. If you are a PM/Coach, it is important to constantly talk to people in various roles in the team and continuously set expectations for the near term. It is also key that people in all roles work together as one team. The mythical man month still holds good in an Agile project and adding more people later in the release will only delay it even further.

Don't let sustainable pace stop you from further improvements

The classical XP/Agile view of velocity relies on a graph which indicates that the velocity of a team stabilizes over Iterations as the team goes through the cycle of Forming,Storming,Norming and Performing It is also an indicator of team achieving sustainable pace.

A lot of Agile project managers/coaches/leads fall into the trap of sustainable pace, and stop thinking about ways to improve efficiency, one the velocity graph shows signs of stabilization. This also gets complemented by the fact that customers are reasonably happy with the velocity the team is currently achieving.

This often stops Agile practitioners from innovating and coming up with even better means to increase throughput of the team.

As an example, imagine a team merrily churning 20 points of stories in an Iteration on an average and the customers are quite happy with the progress. The team probably has an average build time of 20 mins with SVN as a source control, and most often, if this team is in this happy rhythm , it wont bother about the build time, even though there is scope for improvement there. In my previous project, we moved from SVN to GIT as a source control and it reduced our build time by 70% approx. If someone started doing this in the imaginary team with a velocity of 20 points, they can surely speedup by 5 points atleast, considering the huge number of continuous builds in a day.

Another example which I see quite often is teams getting stuck on to sweet release schedules and not striving to improve further. Sometimes a team starts of with a 6 month release cycle, takes a lot of pain and then moves to a 3 month release cycle. When moving to a 3 month cycle this team, tries to improve their processes quite a bit which can involve things like bumping up the functional test suite coverage to 80%, reducing build times etc... But very soon, the 3 month cycle becomes a sweet spot, if the customer is not demanding any further. The point here is not to reduce the release cycle even further, but do more of the optimizations you did to the build times and functional tests and maybe even more things, which will continue to cut down waste. Unfortunately once the sustainable pace is achieved, inherently the motivation to think out of the box to reduce waste goes away.

There is always scope for improvement in a team. Agile practitioners/leads should always have the hunger to make their team better. Think of building teams iteratively. The Forming, Storming, Norming model itself is an iteration at each stage where the team is getting better. But dont stop at performing. Always be hungry for more and don't stop yourself at sustainable pace.

Why is a Story narrative signoff and Showcase acceptance from a Product Owner important every iteration ?

A proper development iteration will involve the development team working on a user story, and towards the end of it, showcasing what the team has completed. This is not only critical to get feedback from the product owner, but also from a scope management standpoint, which most teams tend to neglect.

It is the responsibility of a Product Owner to sign-off on a User Story narrative before the beginning of the iteration, and see the working software during the showcase. Sometimes Product Owners do not end up doing this because of various reasons, and this can result in the following smells

Story requirements keep changing constantly within an Iteration

A narrative signoff is an agreement between the Product Owner and the Development team around the Acceptance Criteria of the story mentioned in the narrative. Sometimes Product Owners shy away from doing the same because they are not sure what they exactly want in the given story. They also want to work in a mode where they can propose changes to the same story within an iteration, since in their mind, as the team is doing agile , it is supposed to embrace changes at any point in time.

This setup results in story changes leaking into a development iteration and causing a lot of churn, and hence wait in the form of code and testing effort. This also results in a team not achieving sustainable pace with every iteration, because of constant changes in user stories,

A fix to this problem,is to coach the product owner on writing/signing-off User Story narratives well before the Iteration starts. What is also required is to make him/her understand that a change made later in the iteration will come at extra cost. One also needs to highlight the amount of waste generated because of changes being made, and the hidden costs associated with thrown away code etc...The team should ideally work in a mode, where if a story narrative is not signed off within an iteration, it should not be played at all. And once development has kicked off for the story, any change to it, should come in as additional scope request which is up for negotiation.


Stories do not get accepted at the end of an Iteration, and the team does not have a clear definition of "Done" for stories.


If Iterations are planned correctly then towards the end of every iteration, stories developed in that time frame should be showcased to the Product Owner and accepted. Sometimes Product Owners are averse to the idea of "Acceptance of a User Story" and insist on a feature being complete to sign-off. Taking such a stand results in many stories within a release pending acceptance till the very end of a feature. Some Product Owners lean towards this claiming a complete feature is much more testable and makes logical sense than a single user story. If this is happening, then it is either a case of your User Stories not following the INVEST principle or the product owner wanting to delay commitment for various reasons.

Again this very problem should be fixed as early as possible in a project. The practice of acceptance of stories every iteration ensures that the product owner has validated the working software as per his spec every iteration. The feedback cycle is cut short and any change beyond this point on requirement is a new story altogether. More importantly, this builds a lot more confidence in the development team that they are on the right path. Ideally, "Customer Accepted" should be the definition of "Done" of a User story, and only when a story is "Customer Accepted" should it be counted in velocity of the team,

The Product Owner role is critical for an Agile team to work smoothly. A good product owner should not only have an excellent view of the product and domain, but also understand the importance of some of his responsibilities towards the delivery team.

Managing Agile team chaos with smaller sub teams

Agile practices work really well when you are dealing with smaller teams. Small teams are bound to be much more efficient and focused. It allows people to know each other well, while having fun at work. Simply put, it reduces the amount of bloat or waste, and it becomes quite evident when you see the team working.
Ideal Size

I prefer a team to be a max of 2-3 developer pairs. Any number more than this calls for a team to be split into smaller sub teams.

Team composition

Ideally based on features or themes. If you have 4 pairs of developers you are bound to be working on more than one theme or feature. A good Business Analyst or a Product Owner should be able to identify these themes in the functionality being developed. If you do not have 2 broad features, try to club the smaller features based on a pattern or a theme. Never split the team based on infrastructure (eg: UI team, Services team)

Align a BA and a QA to be focused on specific themes. If the features are functionally less complex, then a BA and a QA might be shared across these teams.


Split the meetings, making them shorter and more focused

The idea of reducing bloat also applies to the team meetings. Have separate standups among the smaller sub teams. When you have a max of 6-8 people in a standup, everyone will be attentive, interested and will remember what the first person said in the standup when it ends.

Split the Iteration Planning meetings also according to teams which are focused on tasking and estimating features they are developing. You can even have mini retrospectives with sub teams on a regular basis.


Split the card wall

The story card wall tends to clutter up with cards for 6 pairs of developers. Splitting the card wall into separate ones for each sub team helps in keeping the card wall cleaner and motivates the team to keep it up to date.


Handling dependencies across teams.

There will always be dependencies between sub teams. The teams might share some areas in the code base, builds, QA integration boxes etc... A PM or a lead of the whole team plays a vital role here. A PM will have to be part of both the standups regularly and ensure that dependency blockers are removed by teams communicating effectively. As long as the teams are sitting closely, once can always shout out if there is a show stopper !

The whole team can talk about technical dependencies and showstoppers in impromptu developer huddles/technical standups as and when required.


Managing people rotation between teams

People will get bored working on the same feature. Developers will be bored if they were working in a team just fixing bugs or small enhancements. similar is the case with BAs and QAs.Rotation is also important to allow team members to pair with members of the other sub team.

Any rotation between teams can be done at the beginning of an iteration. 1 person swapping in between two 2-pair teams would be ideal. A PM can also choose to limit the number of rotations based on constraints such as knowledge around a particular area of functionality etc...


Better feedback, pair rotation, and self organization

In a 8-10 people team sitting across a table, people can quickly learn about each others strengths and weaknesses. Knowing each other well automatically allows for a better feedback culture within the team. Pair rotation within 4-6 people allows people to pair with everyone in the sub team.

In a small team people have the tendency to self organize themselves. You will see people take on more responsibilities, sometimes a BA playing a PM hat and proactively planning stories for the next iteration. People will not wait for a retrospective to speak their mind about a certain issue, but shout across the table !


Stitching it all together

The Project Manager of the whole team plays a key role in keeping the sub teams focused and on track. For this purpose a PM can conduct an Iteration Close/Planning meeting with the whole team, showing team members where the team stands on velocity, and scope burn down, along with any team rotations for the next iteration. This could be followed by letting the whole team know the scope planned for next iteration.

Needless to say that team outings and other fun activities would involve the whole team !

Services have business value

When you are on a project which is about evolving a set of services from an existing application, or building from scratch, there is always a lot of talk on the architecture and service governance aspects.

But if you are a Business Analyst on this piece of work, and you are asked to write stories for these services, you will wonder.. "well how can we showcase just services ?". If you have never done this before, you might even conclude that writing stories without a consumer of the service is not such a good idea. A lot of Agilists might argue that having a services story is a bad user story.

This happens because the fact that "Each Service has business value" does not become very apparent. If you look at Amazon WebServices it becomes immediately evident that each of the services have a set of features which can be sold to customers.

Services are a reality in today's world on the web, and people make money by selling services. A story which builds a service to search a book based on ISBN has business value. It does not need to have a pretty front end consumer for you to write a good user story. A temporary client/UI would be sufficient or maybe even functional tests/specs. It is still a good user story. This essence needs to be spread across the entire team, so that BAs and Devs are on the same page on "Good User Stories" for this kind of project.

Both BAs and QAs have to embrace this along with the developers on the team, and look at ways to apply Agile principles considering this, rather than being dogmatic in their approach towards Agile and SOA.

Building accountability in Agile teams - Someone needs to ask the tough questions

Agile teams often find themselves in a difficult position when it comes to accountability of the work done. Agile rightly promotes collective owenership, in the codebase, build environment, and even the story wall.While it is extremely useful to have polyskilled people in the team, it should not hamper the need for accountablity on the delivery of a Story, A Feature and A Release.

One way to build this accountability is to ask the critical questions when there are issues in delivery, and tie it with feedback so that the issue doesnt manifest itself again. This can also be coupled with a bit of coaching.

Examples

Scenario 1 : Customer's testing team finds a bug on a story which was delivered to them.

Question (to team QA) : Is this bug breaking the acceptance criteria of the story ?
QA : Yes

Question (to team QA) : Why was this bug not caught when we tested this story ?
QA : Well, this was working fine on the build I used. It broke in the build given to the customer for testing

Question (to team QA) : Why did we not catch this when we ran our automation/regression suite ?
QA : That is because we have some QA backlog on the automation front. This test isnt yet been added to the automation suite

Feedback (to team QA) : Well, that means we need to catchup on our automation first, before developing anymore stories. Now you understand how bad it looks when a basic bug is found during customer testing. Please take this as a challenge that from now on, any stories you test and give to customer, the customer should not be able to find any bugs in them. We should do all that is required so that a story does not fail at any point again.


Scenario 2 : QAs find some basic bugs during testing of a story. A bug which breaks a happy path scenario

Question (to team Dev pair) : Why was such a basic bug not caught during development ?
Dev : Thats because we had to refactoring as a part of another story which ended up breaking this piece of code.

Question (to team Dev pair) : Why were there no unit tests around this piece of code then ?
Dev : Well.. The unit tests were missing because I was finding it difficult to write tests for this piece

Feedback (to team Dev pair) : We now know that having unit tests around this would have ensured that this code would not have broken during a refactoring session. Simply put, if we had test driven the whole piece, we would not have ended up in this situation. I think we need to practice TDD more religiously. in the team. Let us have ahuddle to see how we can improve this. (Maybe look at some coaching on TDD)

It is the Iteration Manager's role to actually ask these questions and make the team retrospect their delivery, time and again, and learn from mistakes.This will allow the team to build more accountability on the work that is delivered.

How do we do both SOA and Agile in a big enterprise ?

The project I am working on currently is a big enterprise application, mostly structured around the SOA model. Since we evolved a legacy code base, the service boundaries have just started to become crisp and clear. We are slowly starting to think of certain teams in the project owning a set of services, and also deciding on service contracts as a norm.

I am now starting to wonder how this model is going to work with Agile teams.

* Will this force us to do Big Design Upfront ? (BDUF)
* Will this force us to have service level teams ?
* How can we write good user stories (which are testable and showcaseable) for service level teams ?
* How can we structure the teams when we have multiple consumers (teams?) for one service ?
* Will this force developers to communicate using service contracts and documents more than unit tests?
* If we try to encourage cross functional teams, will it put a lot of stress on resourcing, with the need of shuffling people around a lot ?

I do not have answers to any of these yet, and a quick look at the Agile community , also does not give me any concrete answers.

Using FreeMind in Retrospectives

So in the last few weeks I attended a couple of retrospectives for my team, and towards the end I facilitated one for another team.

To facilitate I used FreeMind to jot down points which came up during the retro mapping them using the Mind Map. As people were discussing "What could the team do better ?" , I ended up collating them on the map which was projected on a whiteboard. When it came to voting the top 3 points to discuss, we just asked people to put their votes (read color dots) on the whiteboard against the projected map.

Worked nicely. No use of markers, no dirty handwriting, and the team has their mental map right in front of them. The best part is, to send across Retrospective notes as a soft copy, all you need is to export this map as HTML/Word Doc with one click. You can even click print and give each person a copy of it before they leave the meeting room.




Worth a try guys !

A must read for wannabe Agile PMs

I am usually quite skeptical about management books, especially the ones that provide general management gyan.

But this book, Manage It, is one I would highly recommend, for wannabe Agile PMs who are making their move from using other methodologies to Agile. It is also a great resource for a Dev/QA/BA wanting to try out Project Management.

The thing I like about this book is that the language used is simple, the author is blunt and to the point. The book gets the juice out of timeless classics (eg: Mythical man month, Code Complete, Agile Estimation and Planning, Peopleware etc..) and puts it into one complete Software Project Management book. There is also no need to read it chapter to chapter, just read what interests you and I am sure you would find a lot interesting in the contents.

Inducting people on large Agile projects

For a small to medium size project, one really does not need a project specific induction. A developer for example, can learn most about the codebase, by pairing with developers working on different stories. A similar strategy can be adopted by BAs/QAs.

But on a large project (eg: around 20 pairs of developers working simultaneously), the scale of the problem (of inducting people) itself becomes big. The codebase is growing rapidly everyday, and so is the business functionality that the application provides. Getting people upto speed for such a project is a big challenge. Moreover, if you have people who are new to Agile, it adds yet another dimension to the whole problem.

One solution is to have a project specific induction. The model which we have seen work well is actual project simulation, rather than having days of overview sessions and brown bags.

In a project simulation model, you try to create a project like setting on a smaller scale, in order to provide a safe environment for new comers to learn and come up to speed with the project essentials.

Some key factors to keep in mind while planning this.

Group size

Try to maintain a group of 4-6 new joinees in one batch of induction. The attendees will be much more involved by simply being in a smaller group setting. Ensuring a good mix of people from various roles would be useful, however you might always not have this luxury. If you find that the latest batch of new joinees are only developers, allow for a BA and a QA to act as part time mentors for the induction.


Timeline

The time line should be at least as long as a typical iteration in the actual project. One should be able to complete a couple of small stories of the project within this time frame. A 2 week time line would be ideal.

Mentor

Choosing a good mentor is of utmost importance for an induction to succeed.

Mentor Developer - A seasoned developer, a journeyman on the project who can work with a few apprentices around him will be the ideal fit for this role. He/She needs to have a decent understanding of the codebase and also the domain of the project. This person needs to play a full time role in the induction and is constantly pairing with developers, on some of the sample stories in the project induction. He/She could also take a few classroom sessions on the project architecture, technology choices etc...

Mentor Business Analyst (BA) - A mentor BA is needed to help write narratives for sample stories which the induction team will work on. A mentor BA should also have a good understanding of the business problem that the project is trying to solve. He/She should also be pairing with any new BAs joining the team. This can be a part-time role.

Mentor Quality Analyst (QA) - A mentor QA should help in coming up with test scenarios for the sample stories which the induction team will implement. He/She should also have an understanding of test automation framework (if any in use), and help the new QAs on the induction team to write new test cases.


Sample stories

One needs to come up with a wide variety of sample stories, spanning across various areas in the project, to make the induction more interesting and a better learning experience.

Simple functional stories

Pick some user stories that are simple in terms of business value they add. The story size should be less than the average size of story in the actual project. Implementing this story should allow instant gratification for the induction team. It might be as simple as showing some information in the UI which is pulled out of a database. Try to have a set of stories in this category, which will allow people to touch different areas of the code. The stories should also add functionality across different areas in the application to make it more interesting for new BAs.

Refactoring stories

In a huge system, there is always potential for technical debt cleanup. Lining up some stories which are purely technical in nature will allow senior developers joining the team to question the code and try their hand at refactoring it, and in the process learning a lot more about the architecture.

Gold cards/stories

There will always be those interesting tasks in an application which people would have wanted to work on but never got a chance to do so because of project schedule. This is the right time to get those out.

Simulate a mini iteration

Try to put together a mini iteration plan. the length of this should be such that at least an average sample story can be completed in the time span. Prefer a shorter time line so that multiple iterations can be packed in the induction. Ask one of the mentors to double up as an Iteration Manager and run the Iteration in a similar model a real one. This would mean arranging for Iteration Planning meetings were one would estimate and task sample stories, as well as end of iteration retrospectives which will allow the team to look back and focus on learnings. Try to also use the same tools for story tracking, bug tracking etc... as the real project

The more closer this is to a real project iteration, the better are the chances for new joinees to get adjusted to the processes followed in the project.

Artifacts

Artifacts might include anything from presentations used in sessions, video recordings of domain specific sessions, or even retrospective notes from last induction. A lot of these will help future inductions happening on the project and hence must be preserved carefully, ideally in a wiki which is easily accessible and searchable, so that new joinees can find the materials easily. In a rapidly evolving project a big challenge is to keep these materials upto date. This should happen after every induction at the bare minimum.


Buddies

Ensure that new joinees have someone easily approachable in their project after they complete the induction process. Assign them a buddy who can help them learn the ropes. This will ensure the newbies never feel lost, which is mostly the case on large projects.

Scrum of Scrum bloat

If you are running an agile project divided into more than 3 teams, you will normally end up with Scrum of Scrums. The only problem with this is that it can become unusually longer if each project has a lot of burning issues. And burning issues have the potential of attracting a lot attention, people speaking out of turn, lot of cross talk, and in general a lot more to talk about. To enforce discipline in such chaos, one suggestion that Gabbar gave me was to put up a stop watch of 2 minutes per person. A talking token would have worked if it was heavy enough, but again with people joining over conference call , it doesnt work.

I used this version of an online stop watch and it worked well so far. It is also available for desktops and can be shared over web meetings. People automatically started making their updates crisp and to the point.

What's in a role ?

We are a team of over 100 people. While it is scary, we try to do our best to be as Agile as possible. And it is common sense to most that scaling Agile to fit large teams is quite a difficult task. But while we are at it, one of the things that keeps striking me, is the number of roles we ended up carving out for various teams on a big account. For some reason we have the following roles.. Program Manager, Project Manager, Agile Coach, Release Manager, Business Strategist, Release Analyst, Tech Lead, Lead Analyst, Lead QA... whew !


The other day I was going through this article in Dr Dobbs and one thing which stuck me was the naming of roles they used in organizing large teams. Having someone as a Product Owner, Team Coach, and Technical Owner, gives a feeling to me that roles have more ownership and are not doing vague things as managers. Having team coaches instead of project managers motivates someone playing that role to focus a lot more on building a great team than just crunching numbers for a project.

When I told someone about this, they just felt it was stupid. Maybe I am reading too much into the article and the role game itself.

Continous Monitoring

Well.. Thats the name which Owen suggests in his blog. When I read it, it pretty soon occurred to me that probably thats where I wanted to go with my scope monitor. Not only scope, but real time monitor of your project health.

There are some ideas on using Kodak digital photo frames in work areas for the same purpose, or even sleek LCD displays which can be wall mounted. Owen has uploaded a presentation on that which gives a lot of insight in actually implementing it at your workplace. What do I use now... well currently just a PC with a big monitor near the work area. I am still figuring out a way to put it high up on a wall somewhere.