Using what works
At Infoware Studios, we use a melting pot of methodologies to roll out Agile at client sites. Why? Well if you took any of the frameworks / methodologies as per the book, you will be toying with a theory and not with the practical realities that companies out there are faced with. We very much practice what we preach and on a daily basis we try and test new things out in our own team and on our own projects, before applying it at clients. So we have a solid approach to implementing agile at companies.
Initially when following this methodology, a strict adherence to the framework is advised until a new way of working has been established. As you mature your agile adoption, the rules of the game also change.
We combine and use different methodologies in different types of teams and companies. The most common methodologies that we make use of are briefly explained below.
The Scrum methodology makes use of a dedicated team for a focused time frame in which to complete a set out amount of work. We believe in order to have optimum communication channels, a team’s size should be between 5 to 6 members maximum. Scrum runs in iterations of 1 or 2 weeks. There are other companies that run longer cycles (3 or 4 weeks), but that is not advisable for many reasons. The shorter the cycle the better, as the feedback loop is shorter and it supports better collaboration. Chat to us to understand more.
In those weeks the team focuses on work that was prioritised by the Product Owner and committed to by the team during a Planning session. Planning sessions consist out of two parts. In Planning 1 the focus is on what will need to go into the sprint to deliver on Product Owner’s priority for the development linked to the sprint goal and longer term vision of company and/or product. The details of the requirements are discussed here between the Product Owner and the team. In Planning 2, the team will decide how the work that was committed to should be broken down into tasks. Technical design and implementation approaches are also discussed during Planning 2. We often mold this into a single session and sometimes Planning 2 is chunked up throughout the sprint. Why? Chat to us to understand more.
Grooming sessions are one of the boundary meetings for Scrum. During this session an issue (user story) gets assigned a certain amount of points. Every team member has the opportunity to vote on the amount of points they feel is reasonable for the issue. The Fibonacci method is most commonly used to size stories. The value of this session is really to ensure that the Product Owner is prepared and the team informed. The question is how are you approaching grooming and do you really understand how to set this up to get the most value?
Daily stand-ups are a daily session in which the team give feedback to each other through answering 3 questions: What did I do the previous day? What am I planning to do today? Do I have any impediments?
The Review sessions are there for the Product Owner and Clients to review the user stories that were completed during the iteration. Ideally sign off and next steps should be documented and decided by the end of this session.
Retrospectives are a session for the team to review their own processes and to optimize anything that can be done better in the team. Outside influences that need to be brought under the Product Owner’s (Owner of the Product and Vision) and Scrum Master’s (Owner of the agile processes) attention is also discussed here. The Scrum Master is responsible for making sure that actions identified during this session are implemented.
Download our informative Agile Scrum Circle of Life Diagram to better understand the agile scrum process, by clicking here.
Kanban/Lean involves mapping out an optimum process flow depicting the value stream from start to finish. It is focusing on limiting waste and work in progress. Work in progress limits are defined for each step in the process. The Visual Workflow is very important because you cannot understand and work on a process that you are unclear about. Waste management is also one of the main focuses in Lean. By putting in place progress limits, waste can be managed and scaled down. By continuously reviewing the processes and getting feedback from the team there can be continuous improvements to your workflow and productivity. The process is continuously tweaked to move towards an optimum streamlined process and approach to getting stuff out the door. The team are the ones working with the process and the product; they will know what the frustrations and problems are.
This methodology is commonly used with Production teams as the daily work cannot be planned. Kanban is about improving a system to maintain a high level of productivity. It’s the concept of quick in and out. It is also a way to highlight the problem areas in a production environment to be able to make immediate improvements.
XP (Extreme Programming)
Extreme Programming (XP) is a methodology that focuses more on the technical aspects of continuous software quality improvements. It has a lot of similarities and overlaps to the above 2 frameworks/methodologies explained and is also focused on a willingness to change with customer’s requirement changes. It is also structured to give frequent releases to improve productivity and to give space for the client to change requirements at regular check points as does Scrum and Lean.
Extreme programming also introduced the buddy system for developers to review and test each other’s work, thus avoiding coding all of the bells and whistles which aren’t really needed and part of the client’s requirements, but more importantly to improve quality. It also focuses on frequent communication with the client with the acceptance that requirements will change. It is about having a clear and simplistic view in the code and continuous improvements and reviews. It focuses on principles, practices and values. The common practices are testing first, continuous integration and branching. Very much the techy stuff!
We compliment this with the more process focused methodologies / frameworks.
Scaled Agile framework (SAFE) is a methodology that focus on agile in big companies where there needs to be a framework that focuses on the individual roles, teams, activities and artifacts necessary to make agile work from the teams to the program and enterprise level. SAFE is an agile methodology that is focusing on agile company wise instead of just team wise. It focuses on working progress between the team level development and the business strategy and mapping delivery back to initially set business strategies. In our world we use Jira very effectively to do this for organisations. Contact us to understand how you can move forward on this.
DAD is a methodology that is an extension of the Scrum lifecycle. It has more defined phases that include the project initiation and release activities. DAD looks at a wider set of roles to support an agile implementation within an organisation. Before the release of this methodology we added in some of our own. This methodology is suited for organisations where releases during or immediately after a sprint (Scrum) is not possible and a release team needs to be put in place in order to support rollout to production. This is also more suited for very complex, integrated IT landscapes where lots of inter-dependencies between lots of different systems exist and some of these systems are not maintained in-house but rather supported by vendors and often extended. This poses some problems / issues for organisations and this framework is trying to make agile work in these organisations.
DAD is often a good starting place for larger organisations. Although if the organisation is truly committed to achieving the benefits of adopting agile, they should set goals to overcome the constraints and waste in the organisation that this framework has been designed to accommodate. So the organisation should constantly challenge itself to shorten release into production.