Preparing for an RPA job interview, as a candidate or hiring manager? Check out these RPA-related questions and guidance on developing strong answers.
Agile project management: 4 lessons learned this year
Eighteen years after the publishing of the Agile Manifesto, how do its principles hold up? Pretty well. But we’ve also learned some new lessons for agile teams
Agile officially grew up in 2019. Eighteen years have passed since the publication of the Agile Manifesto that helped popularize the movement. We now have nearly two decades of experience in companies from startups to global giants, software product developers and old-economy manufacturers, and even government at multiple levels.
[ Read also: Beware the dark side of agile project management. ]
From my perch as a longtime practitioner (in a software company and two large financial institutions) and as an observer and writer, here are the top four agile lessons I learned this year:
1. Agile is not an excuse not to plan
The Manifesto urged us to value responding to change over following a plan. But as the Manifesto itself emphasized, this doesn't mean we do not value planning at all. The majority of agile programs seek specific results, and projected dates and costs matter.
The most successful program I saw in 2019 implemented a highly configurable software package that re-platformed a complex business. The team spent five solid months building out detailed designs and estimates before beginning incremental development and testing in two-week sprints. Not a typical approach, and not what I’d normally recommend, but in this case, it was just right.
Do the planning your work needs.
2. Don’t skimp on physical co-location and dedicated team staffing
Two Manifesto principles state: “The most efficient and effective method of conveying information to and within a development team is face-to-face conversation,” and “Business people and developers must work together daily throughout the project.” This year I saw these principles proven over and over.
Physical dedicated collocation raises several questions, such as:
- What should the space look like? The space should be open for collaboration but provide quiet and privacy as well.
- Does everybody need to be in the room? No, you can still leverage offshore or offsite teams. But you need a very strong linkage/representation in the room. You can and should also schedule times when certain parties or groups are all present.
- What are the cost implications? Having dedicated people co-located will increase the expense of the initial projects. For instance, instead of a part-time user experience expert jumping from project to project, she will be fully immersed in just one. Travel expenses will also grow if your team is distributed. The upside is that each project done in this way will be done better. Over time, as the collocated teams take on more work and this becomes the standard way of working, you will see cost-effectiveness.
- Do we just do one agile project together, or is this how we work forever? It can be both, but the trend is towards forever. The movement towards a “product, not project” focus is strong, but don’t go overboard. There will always be a place for projects.
3. Agile and Scrum are not synonyms
The first Manifesto value is “People and interactions over process and tools.” In 2019, with accelerating adoption, we’ve seen groups neglect this value by engaging “agile coaches” who primarily teach the scrum method and help implement supporting tools. Leading with process and tools can accelerate agility, but the approach won’t adjust and sustain it.
Scrum helps implement many agile values and principles, and I’m a big supporter. But the range of team compositions, missions, and organizational as well as market contexts is very broad. In each agile organization, these change over time. I’ve seen too many teams blindly stuff user stories into Jira in the last few years, so now I increasingly emphasize leadership skills over scrum process skills. I advocate a leadership model that emphasizes rigor, alignment, and efficiency. Great leaders can implement agile principles that fit, whether it is your own form of scrum or another approach.
[ What tools can help? Read also: Top 7 open source project management tools for agile teams. ]
4. Organizational leadership matters
The Manifesto usefully emphasized the team as the primary unit of delivery. Organizational leadership was mentioned only in terms of supporting the team: “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” Eighteen years in, we now understand that organizational leaders have important obligations, which include:
- Optimize team configuration. Be sure teams have the right skills, leadership, and roles. Organizational leaders may need to facilitate specialization in test strategy planning, technical project management or — my favorite — the lean-derived Chief Engineer for technical team leadership. And typically, only organizational leaders can remove poorly performing team members.
- Connect the team to the larger organization and to partners. Be sure information flows both ways and that leaders of collaborating groups are engaged.
- Be there to make decisions when needed. One program this year started off with an agreement of “light governance” aimed at encouraging team autonomy. Nevertheless, a team leader noted in retrospect that his daily 7:30 a.m. meeting with the top business leader was one of the key factors in the program’s success.
As agile enters its full adulthood, it is remarkable that most of its values and principles have proven their enduring value. That is the biggest lesson learned in 2019 — that agility is not a fad, and that people over process is in its rightful place as the first agile value.
[ Culture change is the hardest part of transformation. Get the eBook: Teaching an elephant to dance. ]