Lessons Learned Working with Pigs and Chickens   

By Ryan Rigby, Consultant   
I have worked as a Scrum Master, Product Owner or Business Analyst on Agile projects for the last six years.  Like many people I come from a background of Waterfall and Iterative software development, and found the transition to Agile initially challenging. Since then I have become a firm believer in Agile development and the need for companies to adopt it. 
For those of you who are new to Agile, “pigs” are the members of the Agile team and “chickens” are all other stakeholders. These concepts come from this fable: 
A Pig and a Chicken are walking down the road.
The Chicken says: "Hey Pig, I was thinking we should open a restaurant!" 
Pig replies: "Hm, maybe, what would we call it?" 
The Chicken responds: "How about 'ham-n-eggs'?" 
The Pig thinks for a moment and says: "No thanks. I'd be committed, but you'd only be involved!"
Here are some lessons I have learned from transitioning to Agile. 
Lesson 1 – There is only one stakeholder 
Ok I admit this statement isn’t entirely true but the primary goal of Agile is to deliver a product to the satisfaction of the Product Owner. There may be many other stakeholders involved in the project (including end users) but only the Product Owner matters.  
The Product Owner is accountable to all other stakeholders. It is the Product Owner’s responsibility to ensure they solicit feedback from those other stakeholders. The Product Owner is the single wringable neck; they have the final responsibility for deciding the requirements and the priority of the work. The Product Owner is also the person who gives final approval that any work produced by the team is complete (done). 
Lesson 2 – This is not AGILE this is FRAGILE 
There are very few companies that can implement true Agile projects. Many companies come from a rigid world of waterfall or iterative projects, and find it difficult to transition to such a flexible development approach. Instead they implement a hybrid Waterfall /Agile (FrAgile) project. 
Some of the typical ways I have seen waterfall being merged with Agile are:
  • Having requirements analyzed, documented and approved one sprint ahead of development.
  • Testing being performed one sprint behind a development sprint. Or having stop a couple days before the end of the sprint so the testers can test.
  • The last sprint in a release being only a defect fix sprint (no new development). 
Lesson 3 – What documentation? 
The level of requirements documentation needed for an Agile user story needs to be in enough detail to ensure the Product Owner and the development team have a common understanding on what needs to be built. This could be on a napkin, scribbles on a whiteboard, a wireframe diagram or a 50 page requirements document. 
Companies from a waterfall development background tend to have onerous project documentation needs, such as:
  • Describing and modeling the entire Business Domain. Tracing every stated business requirement to a business workflow, business justification or goal.
  • Developing complex requirements traceability matrices that trace every requirement to code delivered and test cases produced. 
Agile sprints tend to be two to four weeks in length. BAs do not have the time available to produce this level of detailed documentation.  
The concern many stakeholders raise is, if you don’t produce this documentation then how can you explain or justify your reasoning for how the system has been implemented and how it supports the business.  The Agile answer to this question is “So what? If you don’t like the way the system is functioning, then just change it”. Create a user story and put it on the backlog, and let the Product Owner decide the importance of the change.
Lesson 4 - Defects vs. Enhancements: Who cares? 
In Agile, any work to be done (enhancement or defects) must be added to the product backlog for the Product Owner to review and prioritize. Defects are treated no differently than enhancements; it is still work for the team to do and it is up the Product Owner to decide whether fixing a defect is more important to the business than developing a new enhancement. 
Similar to enhancements, a defect is written up as a user story. The user story describes the gap in what was originally requested in the enhancement user story and what has not been delivered. 
Lesson 5 – Where’s the accountability? 
One of the things I struggled with when starting to work on Agile projects was the fact that there is little to no accountability if the team fails to deliver on a user story that they have committed to deliver for a sprint. 
In waterfall development, many companies have project quality review teams that perform in-depth root cause analysis of why defects are being raised or project delays. Such as:
  • Was there a gap in the requirements? If so why?
  • Did the Business Analyst follow proper analysis processes and procedures?
  • Did the developer unit test properly?
  • Did the developer read the requirements documents? 
In Agile, accountability is a little different. Firstly success is measured by whether the Product Owner agrees a user story is done or not. Individual team members are accountable to their team in a daily scrum, where each member describes what they did yesterday and what they intend to accomplish today. 
At the end of each sprint, the team has a retrospective meeting to discuss what went well and what could be worked on. There is no pointing of fingers but more a discussion on areas of weakness within the team. The team then explores ways in which it can improve and focus on those weaknesses for the next sprint. 
Lesson 6 – Our next product release will contain something…not sure what 
Waterfall projects are bound by scope and budget, but not by time. Agile projects are bound by time and budget, but not by scope. This means in waterfall projects you know exactly what will be delivered in each release, you’re just not sure when it will be delivered. In Agile projects, you have a fixed number of resources (team members) and a fixed number of Agile development sprints; you are just not sure what the team can deliver within those sprints. 
The Product Owner will tentatively assign user stories to a release. However it’s possible the team may not deliver on all of those user stories or it may deliver more than what was planned. Additionally the Product Owner can re-prioritize user stories at the start of each sprint. Typically this is reprioritizing user stories already planned for the release but the Product Owner can introduce new user stories or bring in user stories from the backlog. 
This means that the Product Owner and the team are never quite sure exactly what will be delivered for a release until the last day of the final sprint before a release. 
The Author 
Ryan Rigby is a consultant with over 15 years’ experience working for a variety of international organizations such as Boeing, ICBC, the United Nations, the Australian Federal government and New Zealand Post.  He is a Past President of the Vancouver IIBA chapter and Advisory Board member to the Vancouver BA World conference.  Certified CBAP, PMP and Agile Scrum Master.
Editor's Note: Stay tuned for the Agile Extension to the BABOK® Guide being published this month for practices, tools and techniques business analysts can use when working on agile teams.