Posts Tagged With: Process compliance stupidity

All form and no (agile) substance?

Plus ça change, plus c’est la même chose

Jean-Baptiste Alphonse Karr’s warning reminds us that it is very easy to ignore the Manifesto for Agile Software Development’s value statements.

We might have done away with heavy project governance, premature or excessive planning, and documentation for documentation’s sake, but if we don’t remind ourselves why our team performs specific agile ceremonies, we are no better than our brethren toiling under the burden of traditional, one size fits all delivery practices.

Let’s start with sprints. Short time horizons should focus our efforts towards delivering value early and regularly while having fixed time boxes enables forecasting when we should be able to complete a release. But if we start treating sprints as phases (e.g. development, testing) or we batch work items within sprints in a waterfall manner, we haven’t really gained benefits from this approach. Similarly, if we don’t respect sprint end dates or we regularly modify the duration of our sprints we can’t forecast effectively.

How about your daily standups or scrums? These are meant to serve as micro-planning opportunities to align team members towards accomplishing sprint goals. They also provide an opportunity to surface blockers in a transparent, safe fashion to ensure these get resolved in an efficient and effective manner. But if team members are absent, we don’t start or end on time, one person monopolizes the discussion, or they turn into status meetings, why hold them at all?

Velocity enables teams to assess their throughput sprint over sprint. Used correctly and with the right underlying discipline on work sizing and backlog management, velocity can help a team forecast. But obsessing over velocity is as bad as focusing on percentage work complete in traditional approaches. When abused velocity leads to progressively reducing quality, erosion of team morale and unhealthy comparisons between team members or teams.

Showcases or demoes give a regular opportunity for key stakeholders to view what has been completed, to provide feedback to ensure that what is delivered meets customer needs, to maintain sponsor commitment and to provide a forum for visible recognition of the team’s hard work. But holding these ceremonies when there is nothing meaningful to demonstrate provides limited benefit to the invitees. Having the agile lead or other team member be the only person conducting the demoes doesn’t give everyone a chance to have their day of glory. And having team members get defensive when constructive feedback is provided about a feature which doesn’t quite hit the mark is just going to further the gap between the delivery team and the customer.

Meet the new boss, same as the old boss” – Pete Townshend

 

 

 

Categories: Agile, Process Peeves, Project Management | Tags: , | 2 Comments

Agile transformations should lead with changing mindset and behavior rather than practices

Like most North American kids growing up in an urban environment, my son learned to drive cars with an automatic transmission. Now that he’s been driving for a year, I’m starting to teach him to handle a manual transmission. While the most visible aspect of this is shifting, the exquisite art (to quote the Bride) lies in the proper use of the clutch. Once a driver develops the feel for a clutch and is able to find that sweet spot between dormant and stalling so that they can get a car rolling without the use of the gas pedal, the rest is mere mechanics.

Golf presents a similar scenario – learning to swing a club is secondary to mastering weight transfer. Through practice, once that skill becomes second nature, the rest of the swing will come. But if we start with the top down approach of learning to swing using the shoulders and arms, it will take much longer to develop a good swing.

Agile works much the same way.

Just because we divide our project’s timeline into sprints, conduct daily standups and bi-weekly retrospectives and ask our teams to self-organize, if the underlying behaviors of senior leaders, mid-level managers and team members don’t change, we are just putting lipstick on a pig.

Behavior and mindset changes don’t happen overnight and it’s not easy to confirm what has changed the way one can when introducing a practice or tool change.

This reinforces the importance of a change strategy for all levels of stakeholders involved with the project. While they might appreciate the benefits of agile delivery, if they haven’t reflected on the mindset changes required, stakeholders will act like chickens when we’d need them to be pigs. Senior leaders, delivery and control partners need to understand how they will need to adapt before they are put on the spot to support an agile project. Embracing the change won’t happen overnight which is why effective coaching is required to enable them to become the advocates we need to champion changes with their peers.

The challenge is that there is usually a demand to demonstrate value from a change in delivery approach within a reasonably short time.

That is why it is best to start with one or two small projects to provide a safe opportunity to try, fail, learn and improve.

Start with practices and tools and Cargo Cult behavior is almost a guarantee.

Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 1 Comment

Run relevant retrospectives!

I wrote a few weeks back that while retrospectives are commonly associated with agile projects they can also be equally useful on traditional ones.

So what are some of the elements required to run a successful retrospective?

Psychological safety

One of my key learnings from the Agile2016 conference was that psychological safety is the number one requirement for a high performance team and its criticality is evident in ceremonies like standups and retrospectives.

Imagine the impact of the team aggressively criticizing one of their own for something which might have been done better during the previous iteration. Not only will it reduce the productivity of the persecuted team member, but the ripple effects of that behavior are likely to affect the team as a whole.

While the team is expected to be self-organized and self-disciplined, in early iterations it will take heightened vigilance and active listening for the Scrum Master or team leader to gently coach those team members who are new to agile into how to appropriately contribute to retrospectives.

Be evidence-driven

It is too easy for subjectivity and personal biases to emerge within retrospectives. By starting the retrospective by reviewing quantitative outcomes from the iteration (e.g. net velocity, new story points, ratio of stories accepted by the sponsor and other key stakeholders to completed stories), it can help team members focus and align feedback. This shouldn’t mean that team dynamics shouldn’t be raised and discussed, but a good team leader will facilitate the discussion in the right direction by encouraging team members to provide specific examples when general statements get made.

Radiate reminders

In my recent article I had written about the benefits of classifying the outputs of retrospectives or lessons learned sessions as reminders, blockers or true knowledge.

Blockers identified during retrospectives likely require escalation outside of the team otherwise they should have been raised during standups and resolved. True knowledge might require changes to the team’s working practices hence they should be sized and fight for their survival alongside requirements, defects and other work items in the backlog.

But reminders need to be reinforced and a good way to do this is to publish a top ten list of reminders using one or more information radiators. Think of this as the project equivalent of those “Only you can prevent forest fires” Smokey Bear advertising campaigns. And if they relate to a physical activity or location, place the reminder nearby to enhance awareness.

Retrospect on your retrospectives

After a few iterations the team should not only share what worked well and what could be improved based on the past iteration, but they should also analyze the most recent retrospective. If none of the outcomes resulted in added value, the retrospective might be perceived as wasted time.

Running regular retrospectives is not an indicator of agility but how they get conducted and the benefits realized through them is.

 

 

Categories: Agile, Project Management | Tags: , , , | 1 Comment

Blog at WordPress.com.

%d bloggers like this: