Let's Check Our Foundation- An elementary way to retrospect

"It is not the beauty of a building you should look at; its the construction of the foundation that will stand the test of time"

While there are many effective retrospective exercises that a team can use for continual improvement, I tried falling back to Agile principles to check how the team is doing fundamentally and then used the findings as an input to an action item.


It is great that our teams are doing Agile well, it is not a bad idea to test how strong our foundation is. So here is an activity that we can perform with teams- Check our foundation (Could not find a better name)


1. Take a print out of 12 Agile principles and put today's date on top

2. Discuss one by one with team to get their understanding on each of them

3. Explain in detail what each principal actually intend to convey

4. Put a happy smiley if team follows it positively, sad one if they don't and a neutral one if they are not sure

5. Brainstorm the reasons for sad and neutral ones

6. Put an action plan in place to improve upon lagging ones, decide upon a time frame and group again to see how much the team has improved. It is advised not to take more than one sad and one neutral smiley at a time.

7.Feel free to involve upper management in the discussion. It will be a good Agile therapy session for them. It will also be motivating for the team to see their manager’s involvement






Iterating above activity for a few times will surely help the team in building a strong Agile foundation and will result into a mindset shift.

This exercise serves two main purposes:

1. Team has an improved understanding on Agile principles and now can relate it to their current work

2. Thought provoking discussions resulting into various improvement areas


Please try it with your teams and share your experiences.

Vanilla Agile Risk Management flavored with some traditional practices

In traditional risk management process, a complete list of potential risks with their priority and a plan to mitigate them is prepared upfront. A lot of time and effort is spent towards these hypothetical risks both in upfront planning and in ongoing monitoring and discussion.

While in Agile, the process is rather emergent in nature. The realization of risk occurs quickly and abruptly. Team gets a sense of it at the earliest possible stage, delay time is less as the risk gets highlighted in the daily stand up, review, retrospectives or release/sprint planning meetings. It is more a real time thing in Agile. But are an application of these Agile practices enough to manage risks in an Agile bound project? Or with little adjustments can the traditional risk management be more powerful with Agile methods?

Lets see how the best of both worlds can be combined for an effective risk management in an Agile project.

Whatever I'm going to explain below is a summary of my experimentation, something that has worked for me and may or may not work for all of us. Please have a look and let me know if you find it useful.


So, How Did I Do It?

•Embraced bare minimum traditional risk management techniques
•Customized it with core Agile principles to make it a lightweight framework
•Applied Agile principles to avoid self creation of intrinsic risks or uncertain events
•Implemented DAD (Disciplined Agile Delivery) framework's approach to identify potential risks in the Inception phase of a release
•Used Product Backlog to manage risks
•Included Story Risk Review as a part of DOR (Definition Of Ready)

Risk Defined: 

Risk is uncertainty that matters, i.e, uncertainty that if realized impacts one or more objectives in either a negative (threat) or a positive (opportunity) (Dr. Alan Moran)

Risk is generally assumed to have a negative impact however it can have a positive impact too, also referred as opportunities. The intention should be to reduce the impact of negative risks, while for positive risks one should try to increase the likelihood of the risk to happen.

Like traditional Risk Management, it is a four step process:

1. Risk Identification:

When: Release Planning, Backlog
grooming , Sprint Planning, Daily Stand Up, Sprint Review.

How: A set of predefined/adhoc questions, discussions

Following is the Risk Breakdown Structure and few example questions that may be a part of the discussion:

Technical Risk- Is User Story well defined with all the open questions answered? ACs clear? Any Technical Challenges? DOD/DOR defined?

Business Risk- Customer Needs Identified? Competition? Business Benefit clear? Economy

Security Risk- Is the solution adequately protected from intruders. Questions that address security aspects, negative attacker stories.

Project Risk- Schedule / Budget Constraints? Availability of resources? Distributed Team, Dedicated PO? Etc etc

Organizational Risk- Politics, Stake holders, Virtual Team etc

Who: By the team, though the ownership is of the Product Owner

2. Risk Analysis 

Risk Analysis is done by deriving following:

-Probability (Likelihood of happening it)

-Impact (Cost, Schedule, Technical Performance, Reputation etc)

-Exposure is the quantified potential for loss that might occur as a result of some uncertainty (Multiplication of Probability and Cost)

3. Address Risk 

Release Risk Register: As suggested by Scott Ambler and Mark Lines in their ground breaking book- Disciplined Agile Delivery: A Practitioner's Guide to Agile Software Delivery in the Enterprise  risk list or risk register should be created in the Inception phase of every release and used as part of the prioritization criteria for work items. This is maintained throughout the project, a sample release risk register may look something like this:

Description	Probabaility	Impact	Exposure	Response	Sprint
New features may require significant rework and skills	4	3	12	Technical Spike - US2031 created for investigation	Sprint 11
Database Scalibility	3	2	6	Pending
Potential security flaws discovered	4	5	20	Security task created. TA2045	Sprint 11
Third party Integration challenges	3	2	6	Neha to sync up with Akamai team to figure out discrepancies and challenges	Sprint 12
Video streaming schedule slipping - Technical challenges	2	4	8	Manav and Chris to pair program to fix it. Task-TA2037	Sprint 13

Probability and Impact are measured on a scale of 1-5 with an explicit definition of what a 1,2,3,4 and 5 means.

Exposure is a multiplication of two. 

4. Risk Monitoring

Risk Modified Kanban Board: It is a visual indicator to track the risk responses. Corresponding responses are tagged with the respective tasks. There are three columns -response Planning, In Progress  and Done. The generic Kanban board is modified to monitor the progress of risk tasks as well.

Release Risk Burn down Chart: 

Risk Management activities in various meetings:

Framework

Risk Register Update:

In sprint review, PO reviews the risks and takes a call on the residual ones, if any. Risk register is updated accordingly. 

Summary:


•Embraced bare minimum traditional risk management techniques
•Used Scrum meetings to discuss risk
•Prepared the Release Risk register and added risk response as a separate task/story in the product backlog or as a sub task of a user story
•Included Story Risk Review as a part of DOR (Definition Of Ready)
•Like ordinary tasks, modified the Kanban board to track risk.
•Used Risk Burn down chart for a sprint/release

I hope this article helped you in getting an understanding of how with little adjustments can the traditional risk management be more powerful with Agile methods. I will also recommend Dr Alan Moran's book 'Agile Risk Management', it is such a good read and you may find it here http://www.amazon.com/Agile-Management-SpringerBriefs-Computer-Science/dp/3319050079

Let me just caution you that there is no prescription to it. I explored, failed, innovated, adjusted and eventually succeeded. However I strongly recommend to follow DAD (Disciplined Agile Delivery)
approach to have 'Proven Architecture' ready first during the early part of the release. Many of the technical risks are related to architecture and by implementing the tricky bits early we can have the just enough Architecture ready to support both functional and non functional requirements.

Whatever I have shared above has worked for me, please let me know how do you manage Risks in an Agile project.

Feel free to leave feedback/suggestions.

Fixed Price Contracts - Doing it Agile way

The basic principle of Agile Methodology is to develop product in small increments based on the regular feedback received at the end of each sprint (2-4 weeks). The feedback often results into change of requirement/new requirement, Agile processes harness change for the customer's competitive advantage. As the project’s scope can be of dynamic in nature, it is advisable to go for “Time and Material” type of contract. Unfortunately, due to several budget constraints clients may still want to opt for “Fixed Bid” one(by the way - Fixed price RFP's are a buyer's way of displaying his/her own company's internal weakness. As long as service providers continue to chase after these thorny bones the market will continue to find providers willing to sacrifice their people for the sake of meeting revenue targets). In “Fixed Price” type of contract – time, scope and cost remain constant.

So is it even possible to work in a fixed bid Agile mode?
If yes ,how to provide the estimates?

Once the Agile mindset and the thinking behind scrum is explained to the client, the need or demand for a fixed bid price is dropped in favor of the client, him being able to continuously “direct” the product. Though if it still has to be a fixed bid assignment, following are a few things that can be done to have an effective estimation:

- Move from fixed scope to fixed size/budget: Scope, time and costs are three constraints of the “Project Management Triangle” where one side of the triangle cannot be changed without affecting the others. To leverage Agile the triangle has to be tweaked to replace fixed scope by fixed size.



-Get the Product Backlog ready: List down the high level features, involve the PO and customer to refine them as user stories.

-Estimate the Backlog in terms of SP: Use Ranges to get an estimate, get the team involved for a couple of hours every day. So considering if the product backlog has 200 user stories,team can figure out a range,lets assume it as 1000-1200 SP.
-Estimate the cost to cover the SP: Based on team's past experience or by running a demo sprint , total SP covered in a sprint can be calculated(Velocity) .For example , a team's velocity is 30 SP in a 2 week sprint which is equal to 3 SP/day = 3SP/6hours=0.5 SP/hour. Dividing the calculated SP range by the SP/hour ,i.e. 1000/0.5(2000) - 1200/0.5(2400) . So the hour range comes to be 2000 Hours-2400 Hours . Multiply it by per hour billing ($Z)to get the estimated range of cost , i.e. 2000$Z - 2400$Z .
-MoSCoW Estimation : Use MoSCoW estimation (Must Have, Should Have, Could Have , Wont have) to bring the features under estimated cost , in case the cost is going over the fixed one.
-Exchange Model: Requirement changes to be handled carefully as it may affect the agreed cost. Prioritization should be done keeping the features (that may give real value to the customer) and the cost (it may incur to the project) in mind. The requirements can be dynamic in nature so the existing user story can be replaced by new ones of same size. It is also called as an “Exchange Model”. The overall size of the dynamic product backlog remains same however the Product Owner (PO) can introduce new user stories that are high on business values by exchanging them with the existing ones of the similar size.

Agile methodology is often considered as a misfit for fixed price contracts as the scope is perceived to be one of the constraint. With the help of this post we have just tried finding a few ways to deal with it , hope it helps. 

                                        

Agile - Scrum Implementation - Grass is certainly greener on your side

Moving from a traditional development life cycle to Agile is like quitting smoking, you know it is good for you but at times the temptation to fall back on the old ways is too strong. This article is mainly intended for newly minted Scrum Masters or for people who are looking forward to implement it effectively in their projects. Yes, a cursory glance with feedback from the Agile gurus and experts will also be appreciated. 

Agile Manifesto : 
Before we start , lets have a look at the Agile Manifesto . Following are the four main points of the manifesto
-Individuals and Interactions over processes and tools
-Working Software over comprehensive documentation
-Customer Collaboration over contract negotiation
-Responding to Change over following a plan

"That is , while there is value in the items on the right, we value the items on the left more"

These simple elegant looking words mentioned above can be deceptive in nature when it comes to practicing them,will explain the manifesto in detail later in the post.

By now,many of you may have perceived it as just another "shout it aloud Agile" post and probably would be thinking of utilizing your time in some better article. Probably something more flashy , creative , dynamic lauding author's prowess as a blogger.
But if you are still here ,  following could be the reasons:
-Your willingness to know the Subject -Agile-Scrum Implementation
-Your willingness to implement it
-If already implemented the your willingness to correct it

I am not sure about  what kind of management support , or what kind of knowledge your team has for Agile-Scrum implementation  , however the good part is you have the will, right intentions to embrace the change and the best part is probably you don't have the in house skills and support on it.
The challenges that you face now while implementing Agile-Scrum in your new project would help you to understand some key concepts that people with experience and expertise on it often fail to.

As per my knowledge and experience following should be the order of Implementation :
-Get your Product Backlog ready : Arrange the requirements in the form of user stories with the priority ones on the top .This will give you an idea about first things first, you can either use excel or any open source/ low budget test management tool for it.
-Set up the sprint length (2-4 weeks) : Sprint length is dependent on agility of the team, frequency of changes and the technical complexity of the project. There is no hard and fast rule for choosing one , however the chosen one should remain same for the entire release.
-Start with basic formal Scrum ceremonies i.e.Sprint Planning, Stand Up , Sprint Review and Sprint Retrospective , you may perform the ones like Estimation and Sizing and Backlog refinement informally for now. Once you get a hang of things , you can start performing the other ones formally too.
-Get a certified Scrum coach or master involved to train the Scrum team, facilitate the ceremonies and maximize the productivity by taking care of Unforeseen impediments.However if the option is just not viable , you may go through some very helpful videos/articles that are readily available over internet.
-Plan your sprint once the refined Product backlog is ready ,by pulling the priority items from the Product backlog to the Sprint backlog. Please keep in mind one very important fundamental of Agile Manifesto while planning the sprint - "Working Software over comprehensive documentation " . Plan your sprint in a such a way that you have something to demo to the Product Owner and other stake holders at the end of the Sprint in Sprint Review Meeting .
-Stand up Meetings :Once you have the Sprint backlog ready , please start the Sprint.Use daily Stand up Meetings to check the health of the sprint and discuss impediments if any.Involve the Product Owner in it so that the team can clarify any doubts. Please keep in mind important fundamental of Agile Manifesto-"Individual and Interactions over processes and tools" . If you are not using any tool please use a white board as your team's Collaboration Hub. Mark up five columns on it - Sprint Backlog, Tasks to Do, Work in Progress, QA Ready and Done. Use Post it stickies describing the requirements on the white board.Apart from it Use daily Burndown Chart to track the progress.
Many projects that have elaborate project plans with detailed Gantt charts have failed. We make the plans so complex and detailed that they're difficult to modify when changes occur. Agile process replaces project plans with release schedules and burn-down charts that can accommodate change. Another Agile Manifesto fundamental comes into picture here- "Responding to change over following a plan"
- Use Sprint Review Meeting to showcase what you have accomplished during the sprint. Typically this takes the form of a demo of the new features. Feedback from the customer and all the other stakeholders are taken . Agile welcomes changing requirements , even late in development. Agile process harness change for the customer's competitive advantage. We practice "Customer Collaboration over contract negotiation " principle of Agile Manifesto here.
- Use Sprint Retrospective to find ways to improve in future sprints.

There is so much to write on Scrum Implementation , I hope the above points can at least get you started on it or if already started can help you in improving the things.One last thing that i would like to caution you against is the temptation that may arise to fall back on to half agile/waterfall kind of methodology due to initial Sprint failures. Congratulate yourself if your initial 1-2 sprint fails as those failures would eventually prove to be the stepping stones of the grand success lying in the bright future.
You may think grass is greener on the other side but if you take the time and put the efforts to water your own grass, it would be as greener.

Futurespective - Predicting the Unpredectible

Apart from the regular Scrum ceremonies - Sprint Planning and Commitment, Daily Stand up, Sprint Review and Sprint Retrospective , a new one has emerged that has proved to be quite effective for ensuring higher productivity across the future sprints.

Futurespective - It is a powerful technique that uses the concepts of Retrospective to make the future better. The idea is simple. Think of your new project and mentally take the team to the final deadline. Assume the project has been a miserable failure, brainstorm about what happened on the project to make it fail thinking of People, Organization, Systems, Processes, Facilities and Logistics and put all ideas up on a flip chart. Now look at all of the things that have been written down as a team. Ask them to vote to determine which of these are starting to happen (e.g. poor communications with Product Owner) in the current project. At the end of the session you'll have a list of priority actions that you should take now to resolve the problems that haven't happened yet. It is like taking a mythical Sprint Plan and then thinking of ways to make it fail.
During this exercise team asks themselves two questions:
 Assume this Sprint is a complete failure, and based on what we've committed to deliver, what are we going to do on this Sprint to make that happen?
 What actions can we take now to stop that happening and make our Sprint successful

Future-spectives help the team to establish practices and collaboration patterns early on that transforms a group of individuals to a real team faster.
This is more of a forward approach than backwards , it is more positive where the team can work together in advance to avoid problems. As a result the team feels more in control and is far more likely to put ideas into actions.