Over the last three years, I’ve worked through various roles within my organization to facilitate the implementation of agile practices. For us, implementing a pure Scrum agile model is difficult, since our internal customers like to be hands on with testing, and want the ability to re-prioritize work several times per week.
I intuit that this applies to other large, non-tech oriented organizations as well. The alignment of team members to strict roles and strictly defined timeboxes is a significant hurdle to implementing agile. Furthermore, legacy IT Operations groups have a hefty amount of inertia to overcome, as alignment to roles like Product Owner and Scrum Master rather than existing job categories is not a simple task due to additional required training, changed career path designations, and organizational politics.
So, is there a way to realize some of the benefits of Agile practices without fully reorganizing existing teams? There certainly is. Just as Scrum was built off of lean management practices, your can lead a shift towards agile by including some high-value agile-oriented practices without reconfiguring teams.
Here is my top 5 list of practices to build an agile mindset into existing teams, without significant operational reorganization:
- Break work down into < 2 week increments
Traditional Business Requirements Documents (BRDs) can be challenging for developers to break down into reasonable increments of work. Furthermore, business requirements may have been misunderstood by business analysts, or even the business owners providing the requirements! Getting development done and reviewed within 2 week periods provides clarity towards a smaller objective for developers, while also providing for feedback and corrective actions, if necessary, within a timeframe that will prevent significant re-work delays within a bigger project.
A helpful practice to keep the process fair – summarize key acceptance criteria of the effort where, once complete and working to meet that criteria, the work must be accepted. Any requested work beyond this criteria should be captured within a separate requirement/user story.
Otherwise, at the completion of each small increment of development, the full scope of the increment should be demoed to and/or tested by end users before considering the work complete. This ensures that nothing was missed within the initial analysis or development.
- Prioritize work by value
Another significant shortfall of traditional BRDs is the lack of prioritization. Everything the business owner or business analyst imagines to have value is included within the scope of the document. Usually, little direction is given to what requirement is considered the highest value of a development effort.
For instance, a business user may want a complex process built which involves a daemon monitoring for files in a directory, loading them into the process if filenames meet a specific naming criteria, and for an external system to automate the file drops. This does have some value for the user, who wants to interact with the process as little as possible. But, did you think through the many scenarios actions to taken when the process fails? Will you still need an interface to upload files and report process issues if problems occur? This automated file fetch/load may take a significant amount of effort to build, yet only provide a time savings of a few minutes per month, if it works correctly.
A better approach would be to build an interface to allow for a manual file load and holistic review of the process status within a simple UI, and ensure this component is properly integrated with everything else absolutely essential to the process (a.k.a. the minimum viable product (MVP)). Along the way, perform an assessment to determine what additional features should be added to the scope afterwards, or if there is more value in working towards other work. Orienting work by value can be implemented to your process, regardless of the overall organization of the team.
- Regularly estimate size of work with a team members
Traditional project management is driven by timelines. Deliver X functionality by Y date. Generally, there are people who will not participate in development that have a significant say in how long each component should take, regardless of the actual work involved. Team members are usually involved in the estimate, but do not get a chance to provide a truer estimate of the work as it is broken into smaller increments.
Getting the team to regularly estimate the amount of work via a practice like “planning poker” eventually provides for much better estimates to the effort necessary within any given initiative. This happens by: a) allowing the team to discuss why their estimates differ, and b) gaining ongoing experience in estimating various work items.
In regards to point “a”, I have been amazed by the conversation generated when one team member rates an item as 3 (in our usage, approximately 3 FTE days effort) and another team member rates an item as an 8. Usually it indicates that there is a conceptual gap in the overall scope of the requirement/user story, which can then be clarified on the spot. However, our estimation practice has also exposed simplification of impacts to dependent processes or a lack of knowledge about existing, time-saving templates. Putting all of your “points on the table” is a shortcut to ensure everyone on a team is on the same page.
Point “b” becomes another key skill over time. Estimation switches from being a rare, onerous task, to a routine effort. Confidence in providing quick, reliable estimates grows across all team members. On more mature teams, it’s amazing how consistent the estimates are across team members, and thereafter how consistent the team is in delivering within the estimated timeframe. As a project manager/owner, it makes communicating to outside stakeholders much easier, once you truly understand a team’s capacity.
- Establish a bi-weekly retrospective
A retrospective is an agile event where the team reviews how they have performed over an increment of time. This is generally accomplished through a session where team members (semi-)anonymously post comments on a whiteboard into three categories: what went well, what did not go well, and suggestions what the team could do in the future to make things better. During my time in the Army, we did the same thing but called them “After Action Reviews”.
Performing regular retrospectives allow team members to both celebrate successes and air out bad news in a proactive manner. Usually many comments are on the same things, which strongly indicate issues critical to overcome for better performance in the future.
An important part of the meeting is for the team to truly commit to actionable steps towards improvement, and there should always be something that can improve. This allows for the team to not get mired in bad feelings and ineffective practices for long lengths of time. A period of reflection is key to keep a team evolving into the best, most effective version of itself. And a side effect of this meeting include stronger relationships across team members, and a more positive work environment. What is not to like?
- Provide transparency to all stakeholders
Transparency is key to agile practices.
Within the team, it allows team members to understand each other’s work and the overall team goals. Transparency allows team members to see work in progress by other team members, and help out if they have spare capacity to help towards team goals. It also allows team members to bring others in line, if performance of some members is under expectations. Additionally, skill gaps within team members become more visible, and therefore action to close such gaps may be more quickly resolved.
Outside the team, it allows business owners and product owners/manager to review the present and future tasks aligned to the team, and realign objectives if more critical tasks should be accomplished first. Such transparency enables real discussions of value to occur, to ensure that the upcoming work is as productive as possible. For example, if there are small enhancements on the team’s backlog of work that are merely cosmetic, business owners can align this sort of work for later. In another instance, if one project is competing with team capacity with another project, business owners/project sponsors (really, facilitated via the Product Owner role in agile) will have to understand and make the case for the true value being provided, which would cause one project to proceed with priority with another.
Transparency can be hard. Partly because you can’t hide. If the team is struggling to accomplish certain goals, that will be clear to all stakeholders. If a project or feature without much value is requested by an influential stakeholder, it will likely be challenged. But it is the right thing to do, and keeps everyone honest to the actual work complete and value provided. And ultimately, it should lead to higher value projects and better work for the team.
The items above consist of real steps that any development team can take to achieve a higher level of performance, steps that are generally “built in” to agile approaches. Other agile practices, like timeboxing effort, can help improve performance as well, but is sometimes hard to accomplish if there are several inconsistent, partially dedicated Business Owners or Product Owners working with one team. If you are interested in implementing agile practices in your own organization, working to accomplish the above items can help prove the value of agile approaches, and lead to further organizational support to agile transformation initiatives.