Stage Approach for adapting Engineering Practice
Today’s competitive global market and changing work environment demands that Agile teams possess at least a few Extreme Programing (XP) skills, as they must be able to deliver quality code in small iteration without large up-front design. Practices such as Continuous Integration or Sample Design are kind of a must-have for every team, and more advanced skills such as Test Driven Development or Pair Programming are preferred.
If applied properly with some Agile methodology such as Scrum or Kanban, these practices will allow us to release software sooner, with fewer defects, less money and with more transparency than if we are using Waterfall methodology.
So, if we already know that these practices are so important to overall success, why are so many teams still struggling with implementing them, especially, when many vendors and “domain experts” are claiming that we can learn and successfully apply these practices in real life in 1-2 week classes?
The majority of problems I encounter with more experienced Agile teams are related to inexperienced Product Owners or Engineering Practices. This article provides a summary of my findings and some recommendations for adapting various engineering practices.
Adapting an Engineering Practice is a process and not an event
Many teams already know what practices they need to implement to make their lives better. Yet implementing and making changes in everyday tasks is easier said than done. Even when teams are strongly motivated, adopting a new, healthy habit — or breaking an old, bad one — can be terribly difficult. It is very important to look into the adaption of an Engineering Practices as an ongoing change or long term process and not an event. Teams and organization need to understand this before they start with a journey.
Adapting Engineering Practice for all the right reasons
In my experience, the least effective strategies for the adaption of an Engineering Practice were those that were done by mandate or where fear was present in the person attempting to make a change. Everyone in a team needs to be aware of why they actually want to adapt a new Engineering Practice. So before you start, ask team members how the new practice will enable them to do their work better.
Staged approach is better than a “big bang” approach
The idea is that team moves from one stage to the next. Each stage should include:
- goals that teams identify and agree on
- different strategies that are developed uniquely for successfully completing goals
- new or more advanced techniques that will build on knowledge gained from a previous stage
I have found this model to be more successful than a “big bang” approach, as teams can methodically improve at their own pace. Setbacks that teams encounter along the way are more graciously handled, as it allows teams to retrospect and readjust their goals.
In addition, by using a staged approach, teams can take a break from adding new goals for a certain amount of time until they feel more comfortable with the newly acquired skills or until they are in a better position to work on adding new skills.
Letting the Team Learn--at their own Pace
As much as management might want to hurry their teams to the next stage of development, most teams follow the same general growth and development pattern, which can't be changed much.
I strongly believe that it is not possible to get a team or an individual to progress to a new stage of development before they are ready. Also progress can differ by weeks or even months among teams of the same experience level.
So, if a team is not prepared to adapt to Pair Programing, doesn’t think TDD is necessary, or is still struggling with Technical Debt, even after 12 months working in the Agile environment, should we panic? Not at all. Given enough time, teams will mature and learn. A management’s job is to nurture, encourage and provide a stimulating environment.
We should forget about what other teams did in the same amount of time and think about teams as a unique group of people organized to work together interdependently and cooperatively to meet the needs of their goals. As long as the team progresses and develops new skills as time goes on, then they are just fine.
Establishing the correct goals will ensure the successful completion of the stage
The goals should be very specific and not too numerous. Having too many goals will limit the amount of attention and willpower a team can devote to reaching those goals. In addition, all goals should have a practical way to be accomplished, and they should be created with the consideration of your current sprint.
I hope this article has provided a new way of thinking and a practical approach for adapting new engineering practices. I'd love to hear your thoughts in the comments.
Stay Connected: