Getting products in front of users faster, embracing requirements changes, choosing and trusting solid contributors.
To satisfy the customer through early and continuous delivery of valuable software.
<?>
<?>
<?>
<?>
At Online-PMO, our philosophy is Learning = Training + Practice. To make learning stick, organizations need to ensure their employees are receiving a continuous combination of training and expert coaching.
Online-PMO can help organizations reach their goals, in software testing and security, agile software development, automation, DevOps, and more—through our custom immersive learning approach.
The line separating IT and operational technology is getting blurrier. Will edge computing make or break the IT/OT relationship? IT leaders weigh in.
The Agile Dating Game
The more rigid an organization is about dates, the less agile it can be. Still, it is legitimate for executives to ask for delivery dates, and there are strategies to meet this need, from time-boxed releases to work-forward planning. Yes, executive visibility is possible in Agile. It just takes some compromise and participation.
It is easy for an executive in an Agile organization to feel out of control or sense a lack of transparency, especially regarding delivery dates. Indeed, the executive can view the team’s sprint board and burndown chart and even attend sprint planning, but this doesn’t get them the information they truly seek: “When can I call this product shipped?” As much as the team might push back and say, “Agile doesn’t work that way,” there are strategies that do work to determine “delivery dates” for products, features, and functionality.
It’s not unreasonable for the executive to ask for a date, and the development team isn’t all wrong by not providing one, but the two need to agree to meet in the middle. Here are a few methods that teams use to solve this impasse.
TIME-BOXED RELEASES
This is probably the most prevalent strategy, creating a release calendar and sticking to it ahead of time. This usually means releases every month, quarter, or some fixed amount of time, delivering as much functionality in that release window as possible. Whatever features or stories don’t make it into a release get pushed to the following release on the next previously scheduled date.
Some organizations refer to this strategy as a “release train.” Each release is rumbling down the “tracks” and moving down the pipeline till it winds up in customers’ hands. This usually works because one release is in the process of being shepherded out the door, while another is in mid-development, and a final one is being analyzed and prepared, like boxcars on a train. And missing one train can be okay; another one will be on a regular schedule.
The release train solution helps solve the executive problem of not knowing when something will be available. The releases are generally wide enough apart that the teams can plan correctly, publish a relatively stable roadmap, and provide the visibility that upper management desires. It can also build trust with the customer base, sales staff, and virtually all stakeholders once a few releases are delivered predictably and on time. The downside is that it isn’t especially Agile.
Most release train strategies use multiple sprints per release. For a team that runs two or three-week sprints, that can mean between four and six sprints worth of work wind up in a release and are delivered to customers all at once. This has the impact of stifling the flexibility and agility of the team to change course mid-release or sprint to sprint. As customer feedback begins from the latest release, the current release is already half in development, and reprioritizing what is getting done can be highly disruptive. The other option is to wait for another full release, perhaps several months, before the team can respond to feedback. Neither is an excellent choice for the product owner.
Nonetheless, many Agile teams have figured out how to make this work. Instead of determining which stories will be delivered, they discuss which epics will be delivered. Executives get the visibility and predictability they crave, and internal to a release, the team is left to manage as they want. Even though this comes at the cost of agility, it can work if properly managed.
WORK-FORWARD PLANNING
One of the responsibilities of a product owner is to determine when there is enough exciting functionality that a product is ready for release to the market. This can be done at the story, and epic levels or even contain a collection of epics. Whatever the product owner decides, they say that some group of functionalities is the minimum feature set for the next release. The product owner is also allowed to change their mind, but for scheduling purposes, all we can work with is what we know so far.
Agile has a good process for determining when the functionality will be done or done, done. All epics are decomposed into stories, and all stories are estimated using story points. Some stories will be too big to estimate, and will require further grooming or further decomposition to make them estimable. Once all the stories in the backlog that are assigned to epics in the next release have point values, it becomes a simple exercise to figure out when the work will be complete.
An experienced Agile team will know their team’s velocity, usually measured in story points. It can also look ahead a few weeks or months and determine how many points are available in future sprints to work on the next release. From there, it becomes simple math to set a date. If an epic requires 120 story points of work to be complete, and a team has a velocity of 60, and can dedicate 40 points per sprint to the epic, it will take three sprints to complete all the work. These are only approximations, of course, and the product owner can insert work as they please, and some of the estimates will be either too high or too low, but it does allow the team to choose a date in the future when the features will be available.
As the project progresses, Agile has artifacts to help provide transparency to all stakeholders about how the project is tracking to the original date. Methods such as a burndown chart show how much work was initially estimated, how much was done, how much remains, and how close the team is to deliver on the ultimate deliverable. Some tools will even create burndown charts daily, allowing for up-to-the-minute updates for anyone wanting to look. A similar artifact is known as the Earned Value chart, which shows the opposite perspective: How much value has the team created, and how much more is left? Both charts take into account new requests, changes in estimates, and other factors.
The downside to this approach is that the release date will likely shift continually. As new information is learned, the requirements and estimates will change, which will cause the final date to change, which will also seem like delays and need to be managed from a trusted perspective. The upside is fairly substantial, however. First, it provides good visibility, and perhaps daily visibility, to all stakeholders interested in when the work will be complete. Second, it allows the team to remain agile, as new stories can be added, others removed, and new use cases can be added to existing stories. Finally, the product owner can still declare, at any time, that the work completed is good enough to release. This method puts the decisions in the right hands and provides the right level of visibility. It doesn’t guarantee a date three or more months into the future.
ROLLING THUNDER
The final strategy is the one that puts products out to market the quickest, allows for the most flexibility, and gives the team and product owner feedback as quickly as possible; it is also the least transparent for executives who want to know release dates. I’ve heard this strategy called “Rolling Thunder” as a way to describe frequent and sort releases, sometimes as often as every two weeks, which individually aren’t all that interesting, but collectively become quite meaningful. This would mean that in our above example, rather than waiting for 4-6 sprints to have a release, the team releases new functionality every release.
This method is both the most Agile and the most agile. It delivers customer benefits to the market as soon as they are ready, thereby often getting product feedback. It also allows the product owner and team to course correct frequently in response to feedback from the market and the team itself to make any necessary adjustments. It also provides the least number of valuable artifacts to track progress from a macro scale. Luckily, Agile has a process to get this, but it takes some executive participation.
Agile has two ceremonies at the end of each sprint: a retrospective and a demo. The former is a mechanism by which the team decides what went well, what didn’t, and how things should change. The latter demonstrates what was built in the last sprint and should contain exactly what will be put into the customer’s hands in the upcoming release. An executive willing to trust the process, but still wants to keep in touch with the progress of a team should attend as many demonstrations as possible.
Frequent attendance at these ceremonies gives the leader two different data points. The first is an actual showing of what is coming up in the next release. This could be a new feature, a performance improvement, or an entirely new product. Whatever it is, it’s a way to get a preview of what will be coming soon. It will also provide insight into how the team is working together, the level of quality to which the team executes, and a sense of how aligned the team is around what is essential and what isn’t. In short, if an executive attends this meeting, it will likely tell them all they need to know about the product, the team, and the progress being made.
Once the executive gets comfortable with the team’s ability to execute, they will find that this process works better than the others. However, getting to that point can be difficult and might not be attainable. Without executive participation and attendance, there is no way to know where the team will land, so doing so is critical to creating a high-performing team.
It is legitimate for an executive to ask an Agile team for delivery dates. Lots of things go into a release, and not all are software. However, the more rigid an organization is about dates, the less agile the organization can be. Some strategies have proven to work to meet this need, including time-boxing releases in a train-like structure, allowing each team to set their dates via a work-forward plan, or simply allowing the team to release whenever they are ready. Whatever the choice, it’s essential to know that executive visibility is possible in Agile. It just takes either some compromise or some participation to make it work.
5 Ways to Take an Agile Approach to Manage Constant Change
When everything around you is changing, it may be time to re-think change management. An agile approach to managing change in the workplace is called for, and the traditional approach to change management is no longer sufficient for the rapid change that businesses in all sectors are experiencing.
Traditional Change Management Can’t Cope.
Change management is a structured and careful approach to making sure that changes are smoothly implemented and that there are lasting benefits to those changes. Indeed says that change management is “the methods and ways in which an organization defines and implements various change processes, both internally and externally”… and goes on to list 17 principles (and links to 13 methodologies). Just reading these descriptions of traditional change management can make your eyes glaze over, never mind actually experiencing them.
Change is constant, unpredictable, and fast-moving. It requires resilience and flexibility, concepts incompatible with rigid deadlines and spreadsheets. A strict process doesn’t allow for unpredictability or prepare the workers and managers to cope with radically different outcomes than they’d planned for. So dismissing traditional change management’s spreadsheets, assigned deliverables, and rigid deadlines.
Agile Processes Offer a Path to Navigating the Turbulence.
Treating adjustment to significant, ongoing shifts in how people work and learn as a “project” that can be started and ended on a schedule (remember those rigid deadlines) denies the fundamental nature of the changes we are experiencing. This approach is centered on human behavior and what is needed to change human behavior. Here are five essential practices.