Yow Conference Australia

Looking forward to attend Yow Developer Conference next week.  The conference has pretty good and popular speakers. Some of the popular speakers  include Martin Fowler, Mary and Tom Poppendieck,Linda Rising, Joshua Kerievsky, Eric Evans. 

Leader's Workshop, 2 days workshop by Mary and Tom is going to be an important workshop for me to attend.

This workshop is going to cover the following areas:

• How to discover what customers really want.
• How to look at your process from a customer's point of view and identify waste.
• What's wrong with software testing and what you have to do to fix it.
• How to engage people and stimulate focused innovation.
• Scaling patterns that have proven successful - and their context.
• How to frame risk and rethink scheduling to permit confident promise-dating and reliable delivery.
• Tools for solving problems that everyone in the organization can use.
• Leadership roles that work - from the perspective of followers.
• How traditional governance systems can lead to sub-optimization and what to do about it.

Who is best positioned to write a User Story ?

Someone with a strong domain knowledge is suitable for writing User Stories and It is typically a person close to the business.  Having said that, I strongly believe that  everyone  in a Scrum team should know how to write User Stories.

Reflecting back on Ron Jefferies’s Circle of Life, User stories have 3 key aspects:  Cards, Conversation and Confirmation.

Conversation is the key aspect to be noted here.

This is how a typical User Story writing conversation takes place:

1. Some one from Business (Product Owner(PO) or Business Analyst(BA)) would write the Story on a card.
2. They keep this card on a table and invite the delivery team including developers, architect, testers, etc into the conversation.
3. The delivery team will ask questions to understand the story and in turn BA or PO would make a note of these changes, but any one standing there could pick up the card and make necessary changes to the User Story card.
4. Technical people (Architect, DB admin, etc) get involved if the discussion is tilted around technical user stories.
5. Product Owner is the final approver of all the User stories
 

Depending on the size of the project, dedicated people (typically BAs) should be allocated to write User Stories.
In smaller projects, Product Owners can write User Stories.

Problem with specialization

I  saw the above poster on a closed restaurant near my apartment.

First thing that came to my mind seeing this poster was “Issue with Specialization”.   

Let me share this a bit in detail:

Looking at the poster, it is clear that Chef is unavailable for 4 weeks as he is flying abroad to visit family. Due to chef’s unavailability the entire restaurant is closed for 4 weeks (or until his return).

Since Chef is the only specialist available with no “Cross Functional” team in the restaurant, any issue related to Chef impacts the entire restaurant.

Using this analogy on software development, the projects are at high risk when we have specially skilled team members with no backups .

On a lighter note, while reading the poster, you might also feel that the restaurant is being run by a non-English speaking owner.

Agile Contracts

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Writing contracts is a key topic for the sales team getting involved in Agile projects.  In the  projects applying traditional methodology, companies had zeroed down on two popular models that are: 

1. Fixed Price and
2. T & M (Time and Material)

While working on Fixed price model, software vendors would analyse  the requirements upfront and commit to a price with the customer.  Many a times, the customer fixes a price and the committed bidder gets the project.  

The uncertainties involved in the software development makes this model a flawed one.   As per the popular and well researched  Cone of Uncertainty,  the initial estimate done at the beginning of the software project could be +/- 400%

 

off-mark than the actual calculated at the end.   In order to mitigate these uncertain risks, companies participating in these contracts have to add a lot of unscientific buffer to accommodate them.

Projects applying Agile methodologies is supposed to have a flux associated with them. The scope could change any time and this needs to be accommodated in the contract and this is not easy. This is one of the reasons for Fixed price contracts not being popular in Agile projects. Even though there are several case studies of application on Agile projects but at the end of the day, the constraints imposed by Fixed Price model might actually destroy the agility.

Photo Courtesy: http://www.construx.com/Page.aspx?cid=1648

Time & Material(T & M) as the name implies is supposed to work well for Agile software development as it has no restriction on price or scope. The customer can keep paying as long as the value is getting delivered. However, my observation has been that this model works  well in an established trustworthy environment. 

Several experiments have been made in creating contracts specifically suited to Agile environments.  Some of them include:

1. Phased Delivery
2. Capacity Based
3. Value Based

Phased Delivery contracts divides the entire project life cycle into multiple different phases. A goal is set for each phase and funds are released based on the delivery. The goal could be the number of user stories to be delivered in each phase providing additional quality related info.

Capacity based contracts would provide X number of people for the project  and no scope related delivery constraints are signed.

I am also envisioning Value Based Delivery contract, and I am not sure if some one has experimented with this.  I feel that, either a $ value or some unit could be assigned to Epics or to user stories theme.  As and when this gets delivered, proportionate amount of fund could be released. Again, quality related matrices could be an additional parameter in the contract. 

An Agile practitioner  has put together a list of 10 styles on Agile contracts . check this link out for more details.

Summary
I strongly believe that  Trust and Contract are inversely proportional to each other. That is, as long as we have less trust, we need more contracts.

Copyright protected 2011

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 ?

Tools to build Big Visible charts

The commonly available tools for Agile teams to build "Big Visible charts" include,

   Post-it Notes
   Butcher Sheet
   Flip Charts
   White Boards  

However, while traveling to different countries, and currently in Melbourne I have come across additional tools like:

  Blue Tac 
     Blue tac is like a reusable Gum.  Typically Post-It notes stickiness is not so great.  So, one can use Blue Tac to increase the stickiness.  One can also use Blue Tac to stick the cards, butcher sheet or strings.  Blue Tac can stick to glass panes, wooden boards, etc.  

  Cling on Sheet
      Put it simply, these are reusable butcher sheets
       

Blue Tac                   Cling on Sheets 
 
Ref: orbostofficesmart.com.au

I also found that it is an art to use these tools properly and arranging them in a way to please the eyes. 
 
One can just stick the Post it Notes on the walls  like below:
 

Or, order them clearly by separating them either with the strings or with Cello tapes like shown below:

Ref: brunomiranda.com

What other tools do you use ?

2 Pizza Team

 

 

 

Arrange a Pizza party (not Pasta nor Burgers) before formulating a team structure for a project !    No, this is not to celebrate commencement of work, but to ensure an effective team.  

How can Pizza (not Pasta nor Burgers) help in defining the team structure ?    Let me tell you the story…

I was watching a documentary about the devastating earth quake that hit New Zealand some time back and the way city was rebuilt. The documentary showed the way the city mayor consulted the local residents and got their suggestions for improvement.  I could see the efficiency in which the situation was handled.
 
While I was watching this documentary, I noticed that most of these meetings with the residents had at most 5 – 6 people, and it was very orderly.   This efficient working style triggered many thoughts and came back to my computer to do some research on effective team structures.  
During this search, I stumbled upon this article “Inside the mind of Jeff Bezos”.   In this article they explain, Jeff’s idea of “2 Pizza teams”.  Whenever he encountered problems, he used to divide the problems into smaller chunks and each chunk was assigned to a team of not more than 2 Pizza team size.

So, what is 2 Pizza team size  ?
If you can't feed a team with two pizzas, it's too large. That limits a task force to five to seven people, depending on their appetites.

It seems even, Apple Inc follows similar concept !

Scrum recommends 7+/-2 as the optimal team size  but I guess, this number closely follows 2 Pizza team concept.  One of the major problems with larger teams is less accountability.   There are researches to prove that individual productivity reduces in larger teams due to this concept of social loafing.  As the number of people in the group increase, people tend to feel devalued.   One can get more details about the research here

So, How large is your team now ?

Understanding Scrum

Even though Scrum has touched souls of most of the software developers across the globe, it still seems to be understood as set of practices.  There are many yet to catch up with the principles behind the Scrum.   In the recent blog, Ken Schwaber  reviews the typical mistakes done by most of the Agilists and specifically large organizations. 

Here is the summary of  key points from his blog post with my 2 cents added in between.  Ken’s comments are in Italics.

1. Our tendency and tooling from waterfall and predictive processes is to view people as assignable, parsed, optimized resources. This works great if you are running a factory line and people are doing simple work. It really sucks if you are trying to do creative, complex work where there are many competing ideas and solutions emerge from interactions.

Even  now I have seen many people using the word “resources”  to mean mostly the “developers and testers”.  Even worst, they are also called many times as “heads” or “bodies”.   This is not only demeaning and disrespecting the people around us, but also shows the lack of seriousness about the knowledge workers.

2. People don’t have measurable capacities when they are performing intellectual, creative work. Things move back and forth between different parts of the brain and some of the best ideas come at 2:00am in bed

This is a radical thought process isn’t it ?   All of us work from 9 to 7 PM shift, and we have to think and complete our work in this duration. It is easy for every one around us to be predictive and work in the same time zone. In reality,  this is not possible.  However, the stress, which reduces creativity can be minimized by removing many of the enforcement on the employees at work.

3.

Last, but I’m sure I’ve missed others, is the idea of “assigned” work. This is a common smell of a development team that is not self-managing. Who “assigns” work if a development team is self-organizing? Development teams select work, figure out how to do it, and go do it. Assignments are a dysfunction.

Most of the issues like “assigning the tasks”,  “Architects doing the estimation on behalf of every one”,  “Project Manager approving leaves”  are the vestiges from the Waterfall era.  It is always better to coach and train the people in the top before it affects the bottom.  As the phrase goes “Fish always rots from the head down”.

You can read the entire article here.



Image courtesy: http://www.dreamstime.com/the-right-way-or-wrong-way-thumb2307359.jpg

Increase in Iteration Duration for benefit

Deciding the iteration duration is not easy. It depends on various parameters like  Duration of the project, Agile Maturity of the team, risk mitigation factors, Project domain etc.   Most of the Agile proponents suggest 2 weeks iterations. 

Typically  2 Weeks iteration looks like :

In a matured Agile team with good domain knowledge, the Iteration Planning duration over a period of time becomes stagnant. In the sense,  that the team need not spend too much time understanding  set of user stories or requirements  during iteration planning. 

For example, The team who has spent 2 years working on a particular domain can easily understand the enhancement requests.

While working with experienced teams, I have observed that whether it is 2 weeks or 3 weeks iteration, the iteration planning duration stayed almost 2 days. In such projects, it is beneficial to extend the Iteration duration to 3 weeks to gain additional 1 or 2 days saved from reduction in effort spent on Iteration Planning meeting.  

User Stories - How detailed it should be ?

During the initial days of requirement gathering session, the product owners end up writing the epics. These epics needs to be broken further down into the user stories .   One common question repeatedly asked by the novice product owners is when is the right time to stop splitting the user stories ?   

If you Google around there are many articles written about this topic. 

Some of the options proposed by various authors include:

1.  Stop detailing when you feel the user story is big enough to be implemented in 3 – 4 days

2. Stop detailing when you feel the user story can be implemented in one iteration

3. Quite commonly referred acronym is the “INVEST” model.  More details about this model can be found here,   
    
I really like the INVEST model however,  if the Product Owners(PO) and developers are new to Agile, the above model will not help them much. I still feel that it looks pretty abstract to them.  

In one of the real world case studies, a group of “new to Agile”  product owners and developers  applying the INVEST model on user stories got into a debate for couple of days. They were not willing to budge with their own understanding of  “What testable” means, as each of them had their own explanation.  

So, just telling some one to follow the INVEST model may not be sufficient.

I have my own opinion about this,  while I am coaching the Agile teams, I recommend an iterative approach to detail out the user stories. Each time the user story is created, I ask the product owners to apply the INVEST principle to begin with and then share it with the development team to check their confidence level . If they are able to understand it easily and say that they can code this story, then probably it is the right size.   If not,  then the user stories needs to be split or detailed out further.  The developers take the important seat here. The developers need to review it because, they are the people on the ground implementing the same.

If the team is working in distributed model with POs  and developers distributed across the globe, then the POs could write the user story on Wiki or JIRA kind of tool . The developers on the other end can write their comments/questions as part of the feedback loop.

A good example of Collaboration

During the weekend reading, stumbled upon this fascinating article which talks about Collaboration  with a real life story.

 

 

 

 

 

Check this article out

 

 

 

Team work is needed, but one should not just nod for all requests. It could take the entire project down.

Funnier ways of implementing Agile projects

Have you observed that every company wants to be known as an Agile company(company implementing Agile methods), but no one wants to really follow Agile by the book ?.

Software Project teams do a lot of Agile tweaking during the journey of implementing Agile to fit the company’s culture. Since, company’s culture cannot be changed so easily, they tend to modify Agile practices to fit the companies needs.  Here are few and funnier ways of tweaking that I have observed :

1. Have start and end dates of project carved on stone, and all the requirements are then tried to fit in between the dates.  But, the coding, design and Test are done in 2 or 3 weeks cycle. All the new requirements that emerge during iteration has to be implemented no matter what within the duration

2. Measure Velocity week after week and set a goal for the team to achieve the velocity

3. Measure velocity of all the Agile teams and standardize the Velocity number (like number of story points to be delivered in an iteration) across organization

4. Project Manager would be renamed as Scrum  Master after the CSM training and he/she would continue doing what they were doing earlier

5. Testers are separated from the main team

6. Testing is done at the end of all iterations with a dedicated testing iteration

7. While signing the contract with the customer, sign the fixed bid contract based on the number of stories

8. Having an iteration duration of > 6 weeks

9. Staffing the project with all senior people with the assumption that Agile projects need only “matured” people. See more myths here

Photo credit: http://www.rgbstock.com/photo/mhAT2b2/so+happy+2

PMI is offering Agile Certification

Finally the PMI, big dinosaur as per agilists,  is offering the Agile certification.  Even though PMI is famous for its waterfallish process support, but its team looks like finally has woken up by the noise Agile methods like Scrum, XP is creating in the universe.

Take a look at PMI’s  Agile website for more details.
On and off, we keep hearing about  Agile certifications being offered by Scrum Alliance and other well known organizations. However, so far many of them have either not taken off successfully or have died down after a brief hype.    Now PMI, too seems to be planning to offer  Agile Certification, need to wait and see if it gains popularity.  check out the  PMI’s Agile Certification FAQ from here.

PMI seems to have taken help from Agile thought leaders like Alistair Cockburn, Mike Griffiths, Michele Sliger, etc  in making the Agile certification happen. These people carry a lot of credibility in the Agile world, and so, we could definitely expect a quality Agile certification from PMI in the end.

 

I still believe that these certifications will improve the knowledge but can’t change a man(or a woman)

10th Year Birth Anniversary of Agile

      Between 11th and 13th of February 2001, the lodge at Snowbird ski resort in the Wasatch mountains of Utah gave the space to Agile Manifesto to be born.  The 

17 people at this logde were not merely talking, relaxing and skiing. They were brainstorming about the issues that software developers (including themselves) were facing every day.  The final day took the birth of  Agile Software Development Alliance.

 

Read the story of Agile Birth here.  

Now after 10 years of  Agile invention, Alistair Cockburn  had organized a reunion event.

 

In addition, 16 out of the 17 signatories will take the stage on Aug 8th at  Agile 2011 Conference.     

During this conference, attendees will enjoy open access to all 17 stages hosting speakers, classes, workshops and special events, plus a stage dedicated to Open Jam: a place for problem solving and collaboration where anyone can convene a session, share questions and quandaries, talk to the experts, demonstrate software and techniques, and experiment with emerging Agile practices and ideas.  

Agile2011 promises a stimulating week of learning, collaborating, brainstorming, and sharing problems and solutions while networking and making valuable connections

Agile Vs Lean

There are a lot of articles on the net explaining the differences between Agile Vs Lean.  There are eternal debates about them too.  But this article AgileVersusLean by Martin Fowler gives the most simplistic explanation about the subject.
In the above article, Martin ends by saying I think of lean as a strand of thinking within the agile community, like a pattern in a rich carpet.

Picture courtesy: http://www.popgadget.net/2008/02/flexible_hanger.php

Importance of Cross Functional Teams

As per the Harvard Business Review professor Tiziana Casciaro, an expert in Organizational Behavior 

“Working with similar people leads to limited perspective and heterogeneous group brings different perspectives to the table and bring truly innovative approaches to solve a task” 


I guess this could be one of the key reasons of having cross functional team practice in Scrum.  In most of the Non-Agile projects, the teams are formed based on architecture layers.
For ex: UI team, Database Team, Middleware team.  

Each of the above is a homogeneous group and there is less innovation.  

However, most of the Agile methods recommend team formation based on the story or Requirement as opposed to the architecture layers.   This would encourage having team members from UI, Database, Middleware, Testing, etc.  working together leading to formation of heterogeneous team.  Heterogeneous teams are found to bring different perspective to the table and thus bringing creativity

Delivering Fast with right technical Debt – Forrester research upcoming Webinar details

  According to recent survey data by Forrester Research, Agile methods are now the predominant development approach. Their success is due to their promise of both delivery speed and business value. But agility is more than short term speed.
Short term speed can actually reduce long term business agility.

This reduction of agility is illustrated in the simple metaphor of “Technical Debt” which describes how short-term decisions that aid speedy delivery can, over time, end up drastically slowing down your ability to deliver value.

Agility means achieving the right balance between speed today and speed tomorrow.

Hear Dave West, principal analyst at Forrester Research discuss how organizations are striking the right balance between delivering fast yet keeping their Technical Debt down so that they can remain truly agile.

Dave will cover the following topics:

  

· The state of Agile development – drivers and current practices 
  

· The rise of Technical Debt
 

· The elements necessary to achieve the right balance between speed and Technical Debt
   

· A checklist for Agile success

Date: Thursday, January 27th
Time: 11AM EDT (5PM CET, 4PM GMT, 8AM PDT)
Please register for the webinar here: http://www.castsoftware.com/Worldwide/events/012711.aspx?gad=blogger