Once you get to the point that you know you are going to have to interface a SAFe release train(s), with a waterfall program run outside your organization, success generally turns on three very related topics.  The three topics are transparency, synchronization, and code.  The timing of when the code from all parties is available and managing when the code can be integrated and tested is critical. Even if both programs produce the right code and the code works as it is expected, each program will produce functional code at very different times.  By definition waterfall projects create code after they have done a large part of the analysis and design while teams in a SAFe release train will have functional, demonstrable code earlier. By the time the waterfall project is ready to write code the agile project will have a significant investment in a code base.   Three suggested approaches (in addition to transparency and synchronization) for addressing the risk generated by the differential in code timing are: (more…)

millaa millaa falls

In our essay, Can Agile (SAFe) Be Interfaced With Waterfall?, we identified three major areas that had to be addressed so that a multiple inter-related programs with different management approaches didn’t turn into a train wreck.  Keeping related programs moving in the same direction is important, and synchronization is critical. In a recent interview for a future SPaMCAST Alan Shalloway, CEO of NetDynamics, reminded me that the more complicated we make work, the more we reduce flow and increase the probability of making mistakes. Staking the organization’s success to integrating two programs moving at different speeds is complicated. Synchronizing successfully requires spending time and money to keep the programs synchronized. Three effective techniques used to implement synchronization are: (more…)

Waterfalls!

In our essay, Can Agile (SAFe) Be Interfaced With Waterfall? we identified three major areas that had to be addressed so that a scenario of multiple inter-related programs with different management approaches didn’t turn into a train wreck. Lack of transparency causes misunderstandings and conflict. However, generating transparency has a cost.  Finding the right balance that fits cost and contract constraints is a goal for every complicated program. Generating transparency requires a specific set of behaviors. Several of the most common techniques for generating transparency include: (more…)

I was recently asked how an agile program could interface with a project developed by an outside firm.  The outside firm was using a waterfall process with a single planned delivery of code. The answer I wanted to give was “don’t do it”, but that isn’t a useful answer. Further context: The person asking the question works for an organization that leverages the Scaled Agile Framework Enterprise (SAFe); using the Essential SAFe instantiation for most of the work in the organization. While several release trains exist inside the organization, they are not closely interrelated. Therefore the organization does not need to leverage Enterprise SAFe. Assuming you cannot avoid having two separate but interrelated and dependent projects with one run by a separate organization and using a different approach than your organization, there are several major issues involved in answering the question. Three of these are: (more…)

The spiral method is just one example of a Agile hybrid.

The spiral method is just one example of a Agile hybrid.

Many organizations have self-titled themselves as Agile. Who wouldn’t want to be Agile? If you are not Agile, aren’t you by definition clumsy, slow or dull? Very few organizations would sign up for those descriptions; however, Agile in the world of software development, enhancements and maintenance means more than being able to move quickly and easily. Agile means that a team or organization has embraced a set of principles that shape behaviors and lead to the adoption of a set of techniques. When there is a disconnect between the Agile walk and the Agile talk, management is often a barrier when it comes to principles and practitioners are when it comes to techniques. Techniques are often deeply entrenched and require substantial change efforts. Many organizations state they are using a hybrid approach to Agile to transition from a more classic approach to some combination of Scrum, Kanban and Extreme Programming. This is considered a safe, conservative approach that allows an organization to change organically. The problem is that this tactic rarely works and often organizations get stuck. Failure to spend the time and effort on change management often leads to hybrids frameworks that are neither fish nor fowl.  Those neither fish nor fowl frameworks are rarely Agile. Attributes of stuck (or potentially stuck) organizations are:

The iterative waterfall. The classic iterative waterfall traces its roots to the Boehem Spiral Model. In the faux Agile version of iterative development, short, time-boxed iterations are used for each of the classic waterfall phase. A requirements sprint is followed by a design sprint, then a development sprint and you know the rest. Both the classic spiral model or the faux Agile version are generally significantly better than the classic waterfall model for generating feedback and delivering value faster; therefore, organizations stop moving toward Agile and reap the partial rewards.

Upfront requirements. In this hybrid approach to Agile, a team or organization will gather all of the requirements (sometimes called features) at the beginning of the project and then have them locked down before beginning “work.” Agile is based on a number of assumptions about requirements. Two key assumptions are that requirements are emergent, and that once known, requirements decay over time. Locking product backlogs flies in the face of both of these assumptions, which puts teams and organizations back into the age of building solutions that when delivered don’t meet the current business needs. This approach is typically caused when the Agile rollout is done using a staggered approach beginning with the developers and then later reaching out to the business analysts and business. the interface between groups who have embraced Agile and those that  have not often generates additional friction, often blamed on Agile making further change difficult.

Testing after development is “done.” One of the most pernicious Agile hybrids is testing the sprint after development is complete. I have heard this hybrid called “development+1 sprint.” In this scenario a team will generate a solution (functional code if this is a software problem), demo it to customers, and declare it to be done, and THEN throw it over the wall to testers. Testers will ALWAYS find defects, which requires them to throw the software back over the wall either to be worked on, disrupting the current development sprint, or to be put on the backlog to be addressed later. Agile principles espouse the delivery of shippable software (or at least potentially shippable) at the end of every sprint. Shippable means TESTED. Two slightly less pernicious variants of this problem are the use of hardening sprints or doing all of the testing at the end of the project. At least in those cases you are not pretending to be Agile.

How people work is the only cut and dry indicator of whether an organization is Agile or not. Sometimes how people work is reflection of a transition; however, without a great deal of evidence that the transition is moving along with alacrity, I assume they are or will soon be stuck. When a team or organization adopts Agile, pick a project and have everyone involved with that project adopt Agile at the same time, across the whole flow of work. If that means you have to coach one whole project or team at a time, so be it. Think of it as an approach that slices the onion, addressing each layer at the same time rather than peeling it layer by layer.

One final note: Getting stuck in most of these hybrids is probably better than the method(s) that was being used before. This essay should not be read as an indictment of people wrestling with adopting Agile, but rather as a prod to continue to move forward.

An effective leader directs and coordinates the team, assesses the performance of team members, motivates team members and establishes a positive atmosphere for the team.

An effective leader directs and coordinates the team, assesses the performance of team members, motivates team members and establishes a positive atmosphere for the team.

Leadership is a very difficult concept to define precisely. I have interviewed many leadership experts on the Software Process and Measurement Cast, and each expert has stressed how important leadership is for teams to be effective. All effective teams have a leader, whether they are waterfall or Agile. The big difference between the two models tends to be who plays the role of the leader.  In waterfall, much of the leadership role falls to the project manager (whether they are the real leader or not), while in Agile who plays the leader is more context specific. An effective leader directs and coordinates the team, assesses the performance of team members, motivates team members and establishes a positive atmosphere for the team.

Leaders direct and coordinate the activities on the team based on their vision of the future.  In Agile projects the product owner often provides their vision to the team. The leader needs to articulate their vision in a manner that inspires team commitment. Leaders also need ensure that team’s goals stay undiluted by extraneous priorities.

Leaders need to assess performance and provide feedback to the team so that learning and growth at the team level becomes continuous. In Agile teams the scrum master gets the team to assess themselves and then to take action to change and grow during the retrospectives.

The leader will also help motivate team members. Leaders need to display concern for people and their performance while being fair and impartial. The role of motivator can be anyone on the team. I have been on many teams that the business analyst was the motivational leader while on others the role was performed by the project manager, scrum master or tech lead. In any case someone needs to help motivate the team and part of the ability to motivate stems from the leader’s personal commitment to the team’s goals.

Dr. Mark Bojeun (SPaMCAST 280) suggests that through their attitudes, team leaders influence the team’s environment.  Dr. Bojeun’s research indicates that a leader with a positive outlook and vision creates a positive work environment for the team.  A positive environment influences a team in multiple ways including:

  • Fostering openness to new ideas.
  • Engendering a supportive decision making climate,
  • Providing teams members with appropriate levels of responsibility, and
  • Breeding trust.

In most Agile teams, those external to the team generally view the product owner or scrum master as the leader. Similarly, in waterfall project the project manager tends to be tagged as the leader.  Regardless of the method used the role of leader can be played anyone on the team. The only rule is that an effective team needs a leader that is appropriate to the context the team is operating within.

4-3 2013 Fire Escapes

Fire escapes come in many shapes and sizes, and range from utilitarian ladders to metal staircases. Each fire escape is designed to save lives by providing a means to escape if something goes terribly wrong. They are a framework to guide the delivery of an output, in this case, people.

Software development has gone through many cycles, even though as a profession it is still young.  Each cycle has had its own framework built on the experiences of the cycle that came before.  Over time, the frameworks currently in use will evolve to become unrecognizable from those used in the past. Consider the differences that are being exposed as Agile emerges  from waterfall software development frameworks. My daughter asked me, “when is the last time you saw a modern building being built with a fire escape? “

Each era endeavors to deliver as much value as it can, using the best framework available. This drives change and innovation, but in the end the framework you embrace will reflect the constraints of today’s environment.