The five failures of agile tools

HammerInTheHead.htmFor organizations transforming their technology delivery from traditional to agile approaches, there’s a need to evolve team practices, tools, leadership behavior and stakeholder change appetites in parallel to avoid realizing the risks of being agile while standing in a waterfall. Owing to the popularity of the agile movement coupled with mainstream obsession with DevOps, legions of tool vendors stand ready to sell you snake oil solutions to satisfy all of your agile delivery needs.

But before you sign that vendor contract, consider the following five failures of agile tools.

The inability to incorporate different perspectives

A tool suite’s ability to capture of relevant metrics, produce colorful reports or deliver sexy dashboards is worthless if process to enter or maintain the underlying information is not equally user friendly. While procurement decisions are normally taken by those consuming the output of the tools, not including evaluations by project team members will provide those decision makers with all the form but no substance.

An inability to integrate

Agile tooling presents two distinct options. Buy a comprehensive tool suite from a single vendor that covers the whole construction and delivery lifecycle or purchase distinct best-of-breed products and integrate them. If your company is fortunate enough to have limited technology standards, the former approach might work well, but for most larger companies heterogeneity is the norm so the decision is often made to go with point solutions. No harm in this approach, but if integration considerations are not part of the product evaluation process you could end up with functional siloes (e.g. development or testing) dictating the bells and whistles required for the point products which they would primarily use and no one will be focused on end-to-end operability.

No standards, guidance or governance

Few tools will be installed out of the box with the appropriate usage models for your organization baked in. While you could take a hands-off approach to guidance letting each team figure things out for themselves, the free-for-all which ensues will catch up with you when you look at supporting portfolio-level processes or when there is a need to align the work of separate agile teams. While we want to provide flexibility where beneficial at the project team level, there is a need to define a minimally sufficient set of standards and provide all users with tool training as part of their onboarding to ensure they don’t shoot themselves in the feet.

A lack of discipline

Agile success exposes the need for greater levels of discipline than with traditional delivery approaches. Planning and work management tools can help teams objectively forecast when their next release will be ready but only if the team is disciplined about entering and updating the status and size of all work items. Team collaboration environments are a great way to overcome geographic distribution challenges but only if the information uploaded is accurate and complete.

Tools don’t fit the practices

While most tools can be configured, few possess the ability to be fully customized nor is that a desirable practice unless a company wishes to assume the ongoing maintenance of such customizations. Given this, some compromises have to be made on how consistent the nomenclature or workflow is between the tools and the procedures they are expected to support. However if insufficient effort is spent up front in defining the must-haves from a lexicon or process perspective, these gaps will become a source of data quality and team member frustration issues.

Tools can be a powerful enabler, but a fool with a tool is just a more dangerous fool.

 

Categories: Agile, Facilitating Organization Change, Project Management | Tags: , , | 2 Comments

Are you done?

DoneOne of the challenges of traditional project delivery approaches is that team members often treat the completion of their own tasks as proof of project progress. This perception gets reinforced by project managers or their people managers who will give these team members a pat on the back for getting their assigned tasks completed on time.

One of the original twelve principles of the Agile Manifesto is Working software is the primary measure of progress. Teams following an agile delivery approach look beyond their individual tasks to a feature or capability as a whole. It’s not enough that a component has been developed. Did it pass all of its acceptance criteria without regressing previously completed work and are all of its supporting elements equally ready for release?

To help an agile team gain perspective, it is common practice for a Definition of Done (DoD) to be developed by the team. This becomes the standard against which work items are assessed and ensures consistency of understanding between the team and key stakeholders.

But a team’s DoD could still provide the illusion of true progress.

Long lead times for setting up environments, or limited, shared environments are just two examples of blockers which could hamper deployment. In such cases, a deliverable might be ready to ship but customers are unable to realize business value as it can’t be deployed.

In other situations, it might not even be possible for teams to complete deliverables. Requirements for independent testing, lack of access to all testing environments, or an inability to incorporate all supporting elements (e.g. documentation, change management) into the deliverable could prevent the completion of shippable capabilities.

Such constraints are normal in organizations commencing the agile transformation journey, but leadership teams need to ensure that they continue to whittle away at the blockers which impede full delivery. Otherwise we’ve evolved our understanding of progress from an individual perspective to the team level but we still haven’t realized the true definition of done.

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.

Follow

Get every new post delivered to your Inbox.

Join 329 other followers

%d bloggers like this: