Tag Archives: agile

Practicing Anti-Prescriptive Agility

Presented this talk at the Agile NCR 2014 conference.


It’s not just about the language!

This week I’ve been focusing on “inspecting” the agile practices for a team. The product owner of this team has recently relocated to a new office setting up our very first “Distributed Agile” team. Without equipping the team with the right tools/processes before making this change, clearly we set ourselves for driving backwards and losing all the agile momentum built up so far.

As part of my assessment, the very first and probably the easiest forum to get a team heartbeat, I started attending daily scrums. Coming from ThoughtWorks where almost all our projects operate in distributed agile fashion, I was hoping to get a similar picture for every scrum ceremony but quite frankly it was a major disappointment. Standup or daily scrum was done everyday without the product owner being there, scrum master was relatively new to the organization so it was hard for him to push people to be punctual with the timing. Quality of the updates from the team was far from ideal with anyone/everyone just sharing what they worked on yesterday and what they’re planning to work on today. There was no mention of “blockers” by anyone in the team. Not a single person tied the update with any story/epic. This made me dive into their scrum board to understand how so called “user stories” are written.

There goes another chapter of disappointment. There were no user stories on the scrum board, rather the board was occupied with so many of the “engineering tasks” which didn’t clearly define the business objectives the team was trying to solve. The team had even made it worse by writing the tasks themselves during sprint planning meeting (as the product owner was in US, supposedly more focused on customer facing initiatives). As they’re now writing engineering tasks instead of user stories, obviously estimation is going to be a challenge. To make estimations easier team actually started using number of days as the measure followed on fibonacci series, meaning 1 day effort eqauls 1 point and 3 days effort will be 3 points story and so on. This made things worse as the team started deviating from the “complexity of the task” towards “how long will it take to fix” mindset. Obviously my next step is to attend the sprint planning meeting. The findings continued and pretty much resonated with most of the above.

What was interesting and goes back to the purpose of writing this post was something more interesting than these “executional mistakes”. While interacting with the scrum master and a senior member of the team, I discovered how it all happened and nobody felt the difference within the team. The senior member of the team mentioned, we are doing all the key ceremonies but just not calling them explicitly the scrum ceremonies. He felt that it’s all about just using the “Agile language” which the team isn’t using, making my assessment so bad. That’s when I had to start acting as a “coach” and not just as an “agile trainer”. After soothing their temper with few mins of random chitchat, I started asking them “pointed” questions like “How do you know that the team is on track for hitting the business objective”, “Tell me what problem we’re trying to solve in this project”, “How do you judge the team morale/energy levels”, “What are some of the things we should start/stop doing to make things better” and so on. As expected, they couldn’t answer most of these questions clearly with supporting data points. That’s when I started re-iterating the “purpose” of the 5 key sprint ceremonies. It was quite evident that at the end of our discussion they were totally bought into following all the key ceremonies going forward. The senior member also mentioned that now he clearly understands why I always say it’s not about following the agile language but rather understanding why we want to be agile helps us get better at it.

Prune the Product Tree Workshop

I conducted the “Prune the product tree” workshop with a group of Product Managers at one of our client. The prezi was quite light weight, mostly used as conversation placeholder and to have a format to the whole workshop.

PS – Embedding the prezi into wordpress – #win, struggled with it for quite some time.

“Transformation secret sauce – Part 1”

“Figure out the why’s early on” – Now a days most of the leaders are trying to get their teams “agile” although very few clearly have an objective behind being “agile”. So that’s exactly what we figured out in early days of the transformation, help the management clearly articulate the benefits they hope to acquire after being agile.

“Keep calm, plan baby steps” – You’re not just trying to introduce new processes, tools but also changing the way people are used to getting certain things done. Plan baby steps of introducing change, keep your teams motivated and don’t forget to highlight the “small wins”.

“Win trust from the people than from management” – If you win trust from people on the ground, it’s often easier to propagate the change more than giving them hours of gyan in trainings and meeting rooms.

Stay tuned for the next set of ingredients for the perfect transformation secret sauce!

3 in a row!

I’ve been part of 3 discovery/inception workshops in last 3 months. It’s been an amazing experience to work with some of the smartest ThoughtWorkers. Needless to say, different people bring in different perspectives, skill sets and I’ve learnt a lot from them especially around inception preparation, workshop facilitation, product management/lifecycle and in general keeping myself motivated while going through extended work hours, excruciating travels and depressing weather!

I am going to share few of the key techniques and learnings mastered over this journey.

1. Coming up with an agenda

First and the foremost, don’t spend too much energy in planning the agenda for these workshops. It’s important to make sure you have key stakeholders involved, if there are too many of them, block their calendars upfront. Try and come up with objectives for the entire inception duration based on your understanding of the client problem. Now work backward from these objectives to the workshop sessions. Think about which workshops/sessions will help you achieve these objectives. Key is having a rough plan and revisiting the plan every evening after daily retrospective with your team. Here’s what worked the best, a simple To-do, Doing, Done chart.


2. Inception preparation

Get your drawing toolset together and sketch out important posters like ground rules, parking lot etc. Effectiveness of your sessions depend on your ability to use these posters! An example is the way you can use ground rules, parking lot in case of arguments, off-track discussions. One of the team I worked with had too many creative heads on it and we decided to make the posters too beautiful, only to realise it made people conscious to put anything on them! No need to over-engineer, make them look neat and tidy that’s it! Along with the posters, make sure you run through a checklist of stationary required if the workshops are offsite. Here’s another example of the most common posters you’ll need on the first day!


3. Inception kickoff

Be confident, start with an ice-breaker session (Refer the gamestorming website for few examples or just use your creativity!) to make people feel comfortable with the new faces around. Keeping high energy level not just being the facilitator but also with the whole group makes a lot of difference. The sessions tend to be intense and it’s difficult to keep brains turned on throughout the day, plan for regular breaks.

Stay tuned for the next post where I’ll share few specific workshop activities from the last 3 inceptions.

Learnings from recent discovery workshop

“Don’t plan for every session upfront, have a rough session plan for first/next couple of days and keep re-visiting the plan every evening.” 

I’ve seen some inception/discovery workshops in the past where teams kick-off with a tight, optimistic schedule for every single session for whole of 2-3 week duration. I’ve also seen people forcing themselves to stick to this plan, even when you have a feeling somewhere back of your mind that you need more time.

However, this approach will only be effective when you have a strong facilitator, extremely involved participation from stakeholders and facilitators ability to shuffle things around quickly and convincingly.