Category Archives: planning

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.


Experience wall – not just a story wall!

Since the time I worked on an interesting time boxed, rapid prototyping engagement with a client based out of London, I’ve been an advocate of making everything visual in the team room. For me, story walls were done and dusted, although there are quite a few benefits of using story walls, they’ve become a stereotype. Just with a little creativity there’s so much more you can get out of them.

Here’s how to get started with an “experience wall”:

Demand wall

Start with the product backlog. I’ve always had hard time visually representing the product backlog. How do we make sure that the product management, development and iteration/project management team quickly gets “just enough” information about what they’re working towards? If your team is working on multiple user goals in a release, how do we keep track of the progress on each of them? Here are the variations I’ve tried

IMG_1994 IMG_2095

Supply wall

This could be the simplified version of your sprint/iteration wall. The specific one in example was for a rapid prototyping, 6 week product idea validation engagement. This essentially serves as a radiator for the development team so depending on the extend of visibility desired, you can tweak the columns.


What we’ll get

Now this is something really interesting. None of the workspaces I had seen earlier ever thought about “visually highlighting” what the product/development/UI/UX team is working towards. Often times, the team only knows about it during sprint/iteration showcase. With this section on your experience wall, you can now visualize the progress, customer feedback, focus areas on wireframes.


Experience wall

Once you bring all these together on a big wall, side-by-side, you’ve set up “experience wall”, not just a story wall! Now forget about waiting for iteration showcases to demo your progress, just walk your customer/team through the wall everyday during standup/scrum meeting and you’ve covered pretty much everything that team’s working on!

Screen Shot 2013-05-29 at 12.49.45 PM


PS – Thanks @Ian carroll ( and @barry ( for the inspiration and ideas while getting this in action!

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.