Managing the Agile rooms

Large Agile projects need larger rooms. Even then, they get filled with  Post-It notes in a short span of time.After some time, It would be difficult to find an inch on the wall to add additional information leading to a chaotic  environment.  Clean, well organized space provides clarity in thinking too.

Some of the key things to watch out include
1. Watch out for stale information on the wall. Find a way to archive the old one.  In one project, we used a large box in a corner to archive old post-its.

2. Post the items in a logical order
3. Identify a few people in the team to manage the wall. Creative people could make a difference.
4. Create a lay out such that anyone entering the room can reach the right information easily.  Without a layout, it looks overwhelmed and confusing.

 

 

 

 

Do you have other suggestions to manage the wall ?

Revisiting 3rd question from Scrum Meeting

 

We all know the most memorable, and the key question of the Daily Scrum Meeting, which is
“What are the roadblocks in achieving my goal” ? 

Typical roadblock answers we hear include:

1. I don’t have the development environment ready yet
2. We don’t have necessary skilled people to augment the team
3. We have not received the licenses yet for the software
4. We have a key person missing in the team

 

 

 

 

 

and many variants of above issues.

The Scrum Master records the blockers, and no doubt takes action on them.  However, over a period of time, my observation has been that,  just sharing the blocker is less efficient. I feel that one should also share the impact of the blocker .

For example the above blockers could be reworded as

1. I don’t have the development environment ready yet, due to which I cannot start iteration 1
2. We don’t have necessary skilled people to augment the team so, we cannot start the project .

Yes, it is implicitly expected that the impact is automatically expected here, but it never happens.

As soon as the “impact” is shouted out, it creates its own listening . It pushes the people to think from the goal perspective rather than just removing the blocker.

Summary:  The answer to the 3rd question could be reworded as
My roadblocks are … . and the impacts on this project are….

Let me know if you think it makes a difference ?

Scrum Practices waste of time ?

Every day in some part of the world, I can definitely feel that one of the software projects is getting transitioned to Agile methodology.   Many of the developers working on these new Agile/Scrum projects feel overwhelmed with the new and different practices.

Let us see the typical practices followed in Scrum :
1. Daily Stand ups

2. Sprint Planning Meeting
3. Sprint Reviews

4. Sprint Retrospectives

By the time these “New to Agile” developers, complete their 3rd or 4th iteration, they will start cribbing and saying,

“Oh, these practices are a waste of time, we can deliver more user stories  if we are allowed to sit and code”.

Agree, they can deliver more user stories, but can they guarantee a superior quality code, a valuable product meeting customer’s requirement ?

Let us see why this is not a smart idea to skip any of these practices.

Scrum is all about  Inspect and Adapt.  
Every now and then, one needs to stop, take a deep breathe, inspect the current set of practices, analyse them well.  If one finds areas of improvement, make a list and strive to adapt the good practices.

Skipping these practices might seem to gain some time, but indirectly it causes more harm than good.

Well known thought leader Ron Jefferies says

In my opinion, if four hours a week[spending on different practices] make any difference, you're cutting things too close. You're likely to make at least one four hour mistake by not planning and tracking.


Summary: Unless you really know what you are doing, don’t skip any of the Scrum (or any other Agile methods) practices. Especially if one is new to Agile, then just follow the book until one gains maturity , experience and good understanding.

Can defect fixing be counted as part of Velocity ?

Many a times developers come back with the question,

Can I consider  defect fixing  as part of the velocity ?

Broadly speaking I have seen following types of answers
1. No, do not track it as part of velocity
2. One  should negate these points from the velocity
3. Track it in a different bucket

Let me explain the above types in detail.
1 & 2. Do not track it as part of velocity and may be one should negate it :  Many thought leaders believe that, tracking defect fixing leads to double counting of velocity. People who advocate this believe in delivering quality code with ZERO defects, each time and every time. Velocity is measured as part of delivering a quality code with no defects.  So, the defect found in the future is nothing but your past sin in creating the defect. They believe that, rather than asking for credits,  deduct the velocity.

Many developers feel that deducting velocity is more like punishment, and punishment will not improve the code quality.  There has to be a better way.

3. Track it in a different bucket :   Instead of worrying too much about deducting or not tracking,  go ahead and track it.   Try to have “Defect Velocity” as a separate bucket. During estimation, one could look at the Defect velocity and plan the “DBT(Design, Build, Test) velocity”.
There will be some defect lurking in the code all the time. Even the complex and popular operating systems  like Windows OS and iOS have defects in the shipped product.
As long as the “Defect Velocity” bucket is predictable, its in a good shape.


Summary: Type 3 feels better than Types 1 and 2

Tell me which type do you follow in your project ?