Avoid gold-plating through agile delivery

goldplateAs it is with jewelry, on projects gold-plating is all form with no substance. The increase in costs is rarely justified by the value provided by superficial “bling”.

It could be an analyst adding in requirements which they came up with on their own without ensuring that those are actually required, a developer who introduces a code change or feature they believe is useful without checking with others or a quality control specialist who decides to test above and beyond approved test plans.

Don’t get me wrong – the intentions are usually good and I’ve yet to encounter an instance of gold-plating which was done maliciously. But it doesn’t matter – gold-plating is work creep.

What’s the worst that could happen you ask?

On a project which follows a traditional or waterfall delivery approach, that innocent feature which the developer added might cause regression to approved functionality but at the very least when it finally gets identified will generate unplanned work for other team members. Scope definitions, requirements documentation and other work products which had been produced, reviewed and formally approved will have to be revisited. And the magnitude of the rework and incremental effort increases the further the project gets into the delivery lifecycle.

But on an agile project, if a work item is elaborated beyond the Definition of Ready or the Definition of Done, this will become apparent a lot sooner. Increased transparency into all development activities reduces the likelihood that such changes will propagate beyond the iteration in which they were introduced. Non-solo development practices such as pairs programming can weed out gold-plating at point of application.

A good agile project team exhibits self-discipline and self-organization. Behaviors which impact the team’s ability to meet its iteration commitments will be addressed swiftly else velocity will decline.

And let’s say the team member who is tempted to gold plate feels very strongly about the specific change they’d like to make. Unlike on a traditional project, there are ample opportunities to review it with the product owner, analyst and other team members to assess whether it merits being added to the work backlog.

Using agile approaches to deliver a project provides no guarantee that gold-plating won’t occur. After all, it is a function of human behavior, not approach or methodology. But agile lifecycles can make it easier to detect and prevent future recurrence.

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

Self-organization is a progression not a transaction

freedomA highly touted good practice for project teams is that they should be self-organized.

Rather than rigidly following direction, team members possess the necessary enterprise savvy coupled with the awareness of what they do and don’t know about the project so that they can come up with the best way for them to plan and deliver the project’s scope. Self-organized teams are flexible so as changes occur to the project, they tailor their approach accordingly. They are also resilient in that while they will rely on each other’s skills, they aren’t crippled by the loss of any one team member and they are ready to onboard and assimilate new team members into their collective.

This is in marked contrast to what is the norm in many companies.

Projects are staffed with an emphasis on resource competency rather than how well they play together. Employee performance programs are geared towards recognizing individual accomplishments over the success of project teams. And enterprise governance policies lean towards favoring compliance with process over satisfaction of control objectives.

Facing these sorts of constraints, is it any wonder that many teams exist in name alone? So when the decision is made to encourage self-organization, this change won’t happen overnight.

Team members who have been used to looking out for their own interests over the success of a team will struggle with the shift to collaboration over consensus. They are also likely to lack the necessary confidence to effectively adapt practices and approaches to fit the needs of a given project. Some might follow an anything goes approach but reprisal for failed projects or broken organization policies is usually likely to be swift. Others might be paralyzed when they request governance bodies for guidance only to be told “It depends” or “You are smart and now we’ve empowered you, so go figure it out“.

Self-organization is a progress, not a transaction.

Coaching on appropriate leadership and team member behavior can help but rarely will there be sufficient coaches in place to address the demand, not can they be procured in a time or cost-effective manner. Definition and implementation of a development strategy based on a coach-the-coach model will be critical.

For process tailoring, initial changes should focus on providing guidance for a limited number of choices where previously a single choice had been prescribed. As confidence and competency increases, constraints can slowly be relaxed.

There have been some instances in recent history where prescriptive dictatorships have been toppled by foreign powers. With projects as it is with politics, if sustainable support mechanisms don’t get institutionalized by liberators before they leave, anarchy rather than self-organization is often the tragic result.

 

 

 

 

 

 

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

Reinforcement for running retrospectives

StartStopRetrospectives are a common, regularly practiced ceremony on projects managed using an agile delivery method.

But why stop there?

There’s no reason that retrospectives couldn’t be applied to traditional projects too, it’s just that some improvement ideas might not be immediately applicable in a non-iterative lifecycle.

But won’t it cost a lot more effort to conduct regular retrospectives rather than waiting till we get to the end of our projects? To defuse that concern, here are some reasons why retrospectives are superior to traditional lessons learned approaches.

We all want to help our company but charity begins at home! Why wait till the end of a project where the only beneficiaries of learnings will be teams on future projects if there is an opportunity to reinforce good practices and course correct on others to the benefit of your project?

Sharing knowledge is a good first step, but actually applying that knowledge is when we now whether the lessons are valid or not. Consider our projects as labs where we conduct experiments. If the team comes up with a proposed change to existing practices, it might sound good in theory, but until we try it for real we’ll never know. Regular retrospectives support the scientific method of formulating a hypothesis, testing that hypothesis via an experiment and then adjusting it based on the results.

Dollar-cost averaging is better than trying to time the market. Conducting lessons learned at the very end of a project or even at the end of a major phase is similar to timing the market. Key stakeholders will need some time to de-stress and gain perspective hence emotions can get in the way of identifying quality learnings. If the project or phase ended very well there might be reluctance to challenge practices while if things went poorly there’s a good chance that patterns which should be recognized and reinforced will get ignored. By conducting retrospectives regularly, unless the team is on a death march, there is less likelihood of an emotional rollercoaster derailing knowledge capture.

One approach to categorizing lessons is to classify them as true knowledge, reminders or blockers. The normal methods of handling reminders when they have been identified at the end of a project are to send out some reinforcement communication or to look at adding them into onboarding and other training collateral. While this has some value, it pales in comparison to the influence which a self-organized, self-disciplined team can use on a team member who chronically ignores or forgets a good practice. With blockers, there is value in communicating those post-project to leadership teams in the hopes that they can be eliminated to protect future projects. But when those same blockers are escalated on a project where they are impacting a looming milestone, there may be faster response.

Increased agility and sustained learning comes from being able to identify and apply lessons in close to real time. Regular retrospectives help us avoid Aldous Huxley’s warning “That men do not learn very much from the lessons of history is the most important of all the lessons of history.

 

 

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

Create a free website or blog at WordPress.com. The Adventure Journal Theme.

Follow

Get every new post delivered to your Inbox.

Join 329 other followers

%d bloggers like this: