Agile methods in software development has gained lot of momentum since earlier 2000. The term agile itself was not introduced in the beginning but rather coined as an umbrella term.
I was trying to look for a picture that I thought should cover all aspects of software development with agile + business aspects. The SAFe model seem to be the closest I could go.
Well don't worry if you do not get this picture completely. Let me provide my own interpretation of software process in agile environment.
Problem definition
I would like to build a software model that works for all stakeholders(Consumer/client, company executes, sales, marketing, product management group, middle tier management and the actual development team and the different aspects of software development.
- Need to have regular / planned releases.
- New features need to be built often
- Respond to customer requests
- High quality
- Team should be highly motivated all the time.
- Less down time
- No ambiguity with requirements
- Within budget
- ROI (no lazy people and no loss of productivity for whatever reason)
- Better work life balance for employees
- Happy minds
- ++++ (add any other feature that you would like to add)
Well, who doesn't want some software model that works for everything. Historically people tried different models. As software is the new industry, people tried to adapt to other industries for learning and implementing a process. Unfortunately few efforts have failed miserably (say for example, waterfall model). Making a hardware is different from software and software development is more prone to dynamic changes.
The Solution
First and foremost, if we want to go in agile way, all stakeholders have to commit to the process and most importantly the spirit of the agile process.
An elegant and simpler process is needed in every department not just software development (sales, marketing etc are not independent).
The team
Right team
We need to have right team of people. So every care must be taken to hire good team. One great hire is lot lot better than 2 mediocre hires.
Right skills
You should have right skills with the team you have. If you just have great DBAs alone, it will not help, you do need great developers, great testers and a great product management group etc.
Process
Let us figure out what we want. Is there a limit of what we want? never, but there is always a list of important things that we want.
Product Backlog
Product owner is responsible for building the requirements, what we want to build and why we want to build (value to customer). It is not too common to have hundreds of requirements, but then what is that that you really need it (must) to make this product go live and reach customer? You can always prioritize. Please note If Everything Is A Priority, Nothing Is A Priority. So get the MMF (Minimum Marketable Features) that you would like to have in the product. Make stories.
Story
Write requirements in terms of stories. What is a story? there is a common format that you can use or make something of your own
As a <type of user>, I want <some goal> so that <some reason>.
The stories product owner can think of for entire product should be preferably a double digit (80 to 120), lesser the better.
Snake and size
Write them on the cards. Call for a meeting, through all the cards (with stories) at the team, explain them the vision of the product and let the team read and order them in relative sizing. It is about which one looks simpler (relative among the stories) and order them by their size. Eventually it might look like a snake.
Now, let the team provide estimates too for the stories. Again the estimates are relative.
The best thing i liked here is the relative sizing. If you see a building and someone asks you "the height of that building", you might find it difficult, but at the same time if there are multiple buildings and if someone asks you to tell them in the order of height (ascending or descending) it is lot easier for you do do this task.
So team will not do absolute estimate (no hours or days effort calculation) but just relative sizing.
This helps product owner with a view of complexity from implementation perspective and brings everyone with same level of understanding.
Also it might help product owner to take out some stories if the dev team estimations are too high.
Definitions:
The best thing i liked here is the relative sizing. If you see a building and someone asks you "the height of that building", you might find it difficult, but at the same time if there are multiple buildings and if someone asks you to tell them in the order of height (ascending or descending) it is lot easier for you do do this task.
So team will not do absolute estimate (no hours or days effort calculation) but just relative sizing.
This helps product owner with a view of complexity from implementation perspective and brings everyone with same level of understanding.
Also it might help product owner to take out some stories if the dev team estimations are too high.
Elaborate
Now, next task for the product owner is to elaborate the stories. Well, at least some of them (ideally sufficient stories that could keep team busy for 2 to 3 sprints). Provide each story with details.
If you are starting new teams, then dev team can have their sprint 0 (environment setup, architectural decisions etc) while product owner is busy elaborating the requirements.
Sprint
A sprint is a short amount of time (between 1 week to 4 weeks, but ideal one is 2 weeks) with defined goals (identified stories to be implemented in a shippable/deployable condition).Definitions:
Done
A story/Task can be treated as Done only when
- Implementation is done
- Unit tests are written
- Documentation (inline, wiki)
- Static code analysis is good (no new issues introduced)
- Code review is done
- Code is committed to SCM
- QA is done
- Validated by the product owner
- No regression issues are introduced
- Updated functional and regression test suites as needed
Feel free to add your own criteria to this list before applying this to your agile implementation. The definition of done can vary for project to project and company to company.
Ready
A story is said to be Ready only when
- It has all details provided
- All dependencies resolved
- Acceptance criteria defined
- Mock ups (for UI stories) or work flows are defined
- No Ifs and Buts in the scope
Feel free to modify the criteria as suited to your project/company.
Sprint pre-planning
Sprint pre planning meeting is an important event. Product owner and scrum master (if possible team too) need to sit together and review the stories that are being planned for the upcoming sprint. Review the scope of each story and validate if everything is good and the story is in Ready state. In case of any ambiguity, missing scope, clarification product owner can replace the story with something more suitable and really in Ready state
(This meeting is usually done few days before sprint planning meeting)
(This meeting is usually done few days before sprint planning meeting)
Sprint planning
All the team members and product owner participate in this meeting. Though driven by Product owner (as he will elaborate all stories in detail), scrum master plays a vital role in organizing the meeting.For every story, product owner explains the details. If there are any questions on the scope of the story, product owner provides required clarifications. Team estimates for the effort for the story. Most often it is done using planning poker but even T Shirt sizing approach too is good.
Based on the previous sprints velocity, holiday plans, actual working days team scrum master will decide the estimated velocity that can be planned for the sprint.
Average estimate or most opted for estimate (as every team member provides his/her estimate, we will go with a suitable/average or most opted estimate) as agreed by all team members is taken as the effort needed for the story.
Also estimates are done in story points (no absolute time factor here)
Daily stand up
Daily standup meeting is done every day and is attended by all team members (developers, testers, scrum master and product owner). The meeting shouldnt be more than 15 minutes and it should be a real stand up meeting (everyone should stand, so that people don't extend the meeting :-) ).Every member quickly talks about
- What is done so far (since last standup)
- Impediments if any (Scrum master will pick up the impediments and clears them off by working with other stakeholders needed)
- What is planned for today (until next standup)
Sprint mid review
Though this is not talked about in agile mentors, I prefer this mid sprint review meeting. Probably to be scheduled for 30 minutes maximum(or regular standup meeting be extended by 15 minutes to discuss mid sprint review). This meeting should really happen at the mid of the sprint. This meeting is to review if we are on track (though we are checking status daily, overall sprint might be in RED because of some tasks taking more time). If we need to change story priorities or if someone needs help within the team they can plan better in helping mutually so that we will reach the sprint closure without any spill over.Sprint retrospective
Sprint retrospective meeting is an important meeting. Team can provide feedback either by the 4L (Liked, Loved, Learned, Longed for) . Simply split the board into 4 quadrants and team members can stick their feedback as applicable.Liked (that went normal, it was OK)
Loved (exciting stuff)
Learned (Something new that I learned in the sprint)
Longed for (Areas of improvements or stuff that need to be sorted out)
or in simplest format of
- What went really good in the sprint
- What are the improvement areas (not so good areas)
- What are the impediments faced in the sprint
Scrum master picks up the aggregated list and entire team together will figure out 1 or 2 things that they will focus in the next sprint (while scrum master is the one makes sure the focus areas are really focused and not forgotten).
Demo
After every sprint, a demo should be organised with all the stories together. We can invite external stakeholders as needed (may be all product management group can attend). Product Owner or QA lead or scrum master can do this demo.best part of the sprint is that we get to do the demo in 2 weeks time. This means business users/customers get to see the solution as quickly as in 2 weeks (assuming sprint cycle is of 2 weeks).
What next? repeat this cycle and keep improving the process as applicable.
Release train
How are the releases taken care? Sprint usually talks about one team and one product manager. In reality, there are many teams and company such as contains multiple practices and lot of teams. So there are going to be multiple teams developing multiple features at the same time.
So product management group (across the company) need to really plan the product/feature development in a specific order.
There should be integration/system testing sprints planned as per the release plans. A system testing sprint means QA gets time to test the end to end integrations with all features developed so far and developers fix any issues reported. Based on the quality of the product, product management can decide if we are good for a production release. It is possible that there are few bugs left out. As long as they are not critical product management can still go ahead with a release.
