Finger in the wind type assessment for agile transformation (free templates included)

As a principal agile coach, my focus is to energise and inspire developers to adopt and follow through on the agile frameworks across our teams. When most of the developers did not like the metric of velocity, we tried something different. Instead of relying on velocity or adherence to processes, we measured the teams’ true agility by assessing their growth and capability, not just productivity. We felt this could be done by reflecting how closely their behaviours, actions, and decisions aligned to the core agile principles.

We introduced a radically new approach to tracking our journey of agile transformation. We started by creating an environment where these four behaviours were actively encouraged across the teams in the context of their agile journey:

• Experiment: Let us keep it fresh
• Share: Let us start with what we know
• Listen: Let us observe and reflect
• Learn: Let us develop ideas and understanding

When teams were given the freedom to experiment and develop their own flavour of agile, there was a lot less resistance and a lot more enthusiasm for continuous improvement. Since the teams were actively sharing, we started cross-pollinating the ideas and information into other teams. The teams were now mature, and self-correction started to happen whenever something didn’t work out as expected.

A new approach: Agile Reflection Deck

We developed the Agile Reflection Deck, where we divided the 12 agile principles into three templates consisting of four principles each. After each iteration, the team would reflect on how aligned they were with each of the principles and rate themselves on a scale of 1 to 10.

As the 12 agile principles are universal and generic, the teams had to engage in a lively discussion to gain a consensus on what each principle meant for their team. Then they had to average the team members’ ratings and plot that number on the axis where the agile principle was listed.

As we were a highly distributed team, we used online survey tools to capture the ratings during video conference sessions and then displayed them on the Agile Reflection Deck. Once we had the four ratings mapped onto each axis, we connected the dots to form a quadrilateral. Over time, the shape and size of this quadrilateral gave us a clear picture of the teams’ agile mindsets.

By allowing the teams to self-reflect and analyse how closely they were aligned to the agile principles, we were able to improve and grow with each iteration. During these few Sprints, when this experiment lasted, the teams did map their own journeys and made self-corrections to chart their course to agility.

Here are the three templates that you can use and try out the approach for your own team’s retrospectives.

1 – Agile Principles Quad 1 to 4 – Retro Template

2 – Agile Principles Quad 4 to 8 – Retro Template

3 – Agile Principles Quad 9 to 12 – Retro Template

Sprint Retrospectives One Pager: The Why, What and How

The Why:

Retrospectives allow the scrum teams to reflect on the sprint cycle by highlighting successes and issues that they faced during the current sprint cycle. It helps the agile teams to learn, grow, and improve their performance along with boosting their morale.

The What:

Retrospectives are focused on what went well and what didn’t, such as Sprint processes, iteration lengths, commitments, common blockers, feedback cycles, co-ordination with external teams etc. The teams should not be discussing technical issues related to the project, those discussions should be tabled to be discussed separately.

The How:

Step 1: Sometimes it is difficult for the team to articulate specific things, to facilitate discussion the facilitator can ask questions similar to the ones listed below

• Did the team finish the work committed in the sprint?
• Was there work added or removed during the middle of the sprint?
• Did the user stories have sufficient detail for the team to perform the work?
• Are the team members being pulled into managing any other work?
• Are the action items created in the previous retrospective complete?

Step 2: Encourage every team member to participate and gather data as to what went well and what could need improvement. With distributed teams this can be a challenge, so it is helpful to use a tool that will help with collaboration. Its best to supplement video conferencing with with a canvas wherein people can view and edit information simultaneously.

Step 3: Each team member can cast votes on issues that need to be tackled in next Sprint. The top two or three issues which have the maximum number of votes should be picked.

Step 4: The top issues should be discussed by the team to figure out what needs to change, if its within the team’s capability.  Else the issue needs to be escalated to management. Once the team agrees on the possible solution or escalation then action items need to be created along with assigned owners to those action items.

There is no perfect user story so let’s get started already

Most often, I see the teams get cold feet when writing user stories as they are not sure if they are getting it right. My usual response is that there is no perfect user story and that he purpose of user story refinement  is to ensure that each user story has sufficient detail so that it can be programmed, tested, and integrated within a single sprint.

User story refinement increases efficiency of the team by greatly reducing risk by minimizing the unknowns. Having a adequately refined backlog greatly reduces the time required for a Sprint Planning meeting as all the team is able to have common understanding of the development that will be undertaken.

Always start by identifying thin vertical slices of work that can deliver business value. For example if a user login functionality has to be developed, the deliverable would need to have User Interface, Application logic and database tables. As opposed to developing the complete data model in the first sprint, application logic in the second sprint and the UI in the third sprint.

Typically it is recommended to work through enough backlog items that would last about 2 Sprints beyond the current sprint. This is to ensure that the team can still function if the Product Manager or Product owner are unavailable for a week or two.

As a prerequisite, ensure that the backlog is ordered to reflect the business priorities specified by the Product Manager or Product Owner. This will ensure we work on the user stories that have high business priority and need to worked on relatively soon as opposed to later.

User story or an epic? the best way to address this question is to follow the rule of thumb, which is if a user story cannot be completed in one sprint then it has to be split into one or more stories.

It is also a good practice to check if there are any internal or external dependencies for a particular user story and capture the dependency. This will greatly help during the planning session when the team is committing to a bunch of user stories.

Finally, almost all user stories require acceptance criteria, wherein one will specify when a user story can be considered completed or done and working as intended. This will also guide the Test and QE teams members of the team to appropriately write test cases.

Continuous Delivery and Time Boxed Agile Scrum Methodology

One of the questions that came up during our retrospective at a program level is that as we are moving to continuous delivery, the concept of ‘Time Box’ maybe becomes irrelevant. As we are not waiting until the end of the Sprint to deliver or deploy our code into production, then why have these scrum ceremonies or processes?

The basic assumption is that Sprints force a team to release at a particular interval rather than being able to deploy once the code is ready to be shipped, even in the middle of the Sprint. Traditionally this is true, wherein the Sprint Review allow the teams to demo the functionality or user experiences and the Product Owner, signs off on it.

When we move to a Continuous Delivery model, especially when the end product is a hosted web application as opposed to a downloadable piece of software. The notion of waiting till the end of the sprint, adds little or no value.

The best way to handle it decouple the releasing the shippable increment with the other aspects of the Sprint, such as standups, backlog refining, planning, reviews and retrospectives. This approach allows us to keep all the benefits of following Scrum and at the same time embrace Continuous Delivery with no friction.

It is implicitly assumed that when an team transitions to Continuous Delivery that all the related aspects such as planning also happen continuously. This is rarely true, when there is no timebox, teams often fall back into the default mode of very little planning and alignment with the other teams. 

Scrum framework gives us that luxury, wherein we can take a step back at the end of each timeboxed Sprint and reevaluate what has been achieved. Collect and present our findings to the larger group, especially when we are working in an enterprise. Based on the feedback from the users using the newly released features and input from the larger group on the alignment and strategic direction, the next iteration can be then planned.

As a summary, here are three things that will help us to continuously deliver using the same scrum framework

1. Decouple the release or deployment to production from the Sprint Cycles but follow through on the Scrum ceremonies. 
2. Use the timeboxes to emphasise the human aspect of software development – take a pulse of team morale.
3. Examine the interdependencies with other teams and plan them into your next iteration as most projects at enterprise scale are interconnected. 

Scrum Alliance Global Conference Review – Bangalore June 2016

This week, I attended Global Scrum Gathering in Bangalore, the conference hosted by Scrum Alliance. It was quite a rewarding and enjoyable experience. As an added bonus, I got a chance to hang out with Manny Gonzalez, CEO at Scrum Alliance and engage in a discussion of organizational transformation that needs to take place for agile mindset and behaviors to take root. He mentioned Scrum Alliance is actively working on developing coaching sessions for Leadership roles as they face unique set to challenges in transforming the culture in an organization.

As expected the opening keynote session by Dr. Kiran Bedi – ‘Transforming Organizations, Transforming Lives’ was splendid – energizing everyone at the conference. Also loved Manny Gonzalez’s talk, wherein he shared his personal journey and talked about the day he realized that his personal belief systems perfectly aligned with Agile manifesto. An awesome and humble guy as he actively listens to the people unlike many leaders, who are eager to tell you what they think and why their organization functions the way it functions.

The sessions were a mixed bag, wherein some of them had really good insights and shared the different methods and techniques that they used at the organization they consulted or worked with. A few were disappointing wherein they were just interested in marketing their company and services, including the lead sponsor who only tried to market his company, added very little value.

The third day the concept of ‘Open Space’ was introduced wherein hundreds of attendees self-organized to form a learning marketplace. It was as simple as creating 45 minute workshops around any topic of common interests. We basically announce the topic of interest; put it down on a poster along with time and place. Pretty soon you will find people who feel the common pain you might have also been experiencing and you dive into lively discussions which are supplemented with lively discussions.

The topic that I facilitated was ‘How does the role of middle managers change after introduction of Agile in the organization?’ Soon there were 20 to 25 people relating their personal experiences and how they managed to either survive or thrive who transitioned from being Dev Managers, QA Mangers and functional managers. On the other side a few of the executives shared their frustration wherein the managers were unable to cope of with new skill set required and had to be let go.

The image above image was the output of the session, wherein everybody agreed that the role of middle managers should change to that on an Engineering manager or a Product Owner. This new roles are no longer about status updates and acting as information buffer between the teams and senior management. He or she is expected to actively contribute to the team by bring in best practices that facilitate agile development like Test Driven Development (TDD), Development of automated testing and regressions suits, Continuous Integration and Continuous Deployment (CICD) etc

Scrumosa – One pagers on Agile & Scrum in Open Source

Hello Folks, I have been meaning to blog on the subject of Agile and Scrum because most of the material available today focuses on simplistic implementations such as co-located teams. Also they assume a simplistic predefined structure wherein the stakeholders are identified and available at the team’s discretion and dependencies could be worked out within one or more teams within the organisation. 

The complexity is compounded in open source projects because of the varied nature the intermingling of contributors and stakeholders. The team is not only focused on features that were loosely drawn up by the product manager but also works actively on the ones that the community is interested in.

I also hope to address some of the challenges that are unique to working in open source environments, wherein you have to collaborate with not only internal teams but also work with external organisations which sometimes have conflicting interests.

One of the focus areas will be working with globally distributed teams, wherein the team members are spread across different timezones. For example even a simple thing as daily standup becomes challenging due to time zone issues making it impossible for team members to meet at same time.

If you are wondering about the image depicting lightening in a bottle – Well the original expression is “like trying to catch lightning in a bottle”, it describes something that’s extremely difficult, almost bordering on the impossible. That is how I feel, my self imposed assignment would be like, but based on the amount of pain and confusion it can alleviate, the effort will definitely be worth it.

Over the years I have realised that we tend to learn better from short, focused articles rather than elaborate descriptions and detail material. Hopefully, these one-pagers will aid in understanding and adoption of Scrum. 

So, the plan is as follow up with short one pagers, in the context of open source and globally distributed teams.