Tag: Methodologies

The Evolution of Project Management and Scrum: Scrum2

Written by Chris Merryman on May 15, 2013. Posted in Articles. 9 Comments on The Evolution of Project Management and Scrum: Scrum2

The next step in Scrum’s evolution is long overdue. Almost everyone who has spent a few years in the software development world has been exposed to a taste of Scrum. Each organization has their own twist on its implementation, but without a doubt, Scrum is the most recognized and utilized Agile methodology available today. But with Scrum’s use we all hear about its limitations and why it doesn’t work. For instance, “How can I secure people and capital with the lack of planning that Scrum encourages?”, “Scrum won’t work for my distributed model”, “Scrum is too unstructured, we need a reliable approach”, and unfortunately, “unstructured” is one of the more mild words I’ve heard on the topic. The list of limitations goes on. And likewise, in the project management world we hear similar sentiments. The latest Project Management Institute (PMI) Certification (PMI-ACP) is a good step in the right direction but doesn’t bring the two methodologies completely in sync. Being from a project management background and also being a Scrum Master for several teams utilizing the Scrum process, I can attest to some of the shortcomings of both methods; however, combining the two methods could be the evolutionary change that the software development community and their sponsors/stakeholders have been looking for.

In relation to product development, agile methodologies vary widely in their approach. The literature for Scrum is extensive and has many recommendations of how we can encourage a team to self-form all the way to getting a product to market with a minimal number of bugs and getting paying customers lined up. It is not a detailed guide like PMI’s Project Management Body of Knowledge (PMBOK) which provides a fairly detailed guide to get from inception to closeout, but Scrum goes into more depth than the PMBOK when it comes to software development. When speed to market and quality are vital to a project or company’s success I think Scrum handily beats the PMBOK approach. With the speed of software product release, the low tolerance of customers to bugs in the code and the difficulty of securing capital, Scrum provides a faster and more reliable method to get from idea to market with the least amount of overhead.

Sponsors and stakeholders have additional goals in mind: the desire a product to sell profitably with the least amount of overhead possible. For a project to be funded we need capital, and in most organizations a plan must be created to show how not only the product and quality targets mentioned earlier but also how efficiently we can utilize the capital we are seeking, profit margin, and return on investment to name a few. Scrum doesn’t address or focus on this. PMI’s PMBOK, on the other hand, has documented several approaches to address these concerns. To secure capital, we can use project scoping methods, cost-benefit analysis models and a host of other tools that the business community is familiar with and has come to trust over the years.

Let’s imagine we’re not successful in securing capital. Without capital we have no way to get people dedicated to our project, thus no product to develop. We have an idea but no one to work on it. Some teams are lucky enough that they can form with just a few cycles each week to get a product at least to a reasonable inception phase. This applies to start-ups all the way to corporate environments. Maybe we have to do the work after hours, or maybe we have time to spare during work hours. Either way, people have to be motivated to make it work. This is where the “self-forming” aspect of Scrum comes into play. Project Management takes a more formal approach to organization and makes an assumption that people can be assigned to and will work on the project. In situations where this is not the case and we need to find a way to get people together to work on a project quickly, I think Scrum’s approach wins, hands down.

Once a team forms, we can have a few quick meetings for estimating and planning. Both Scrum and Project Management methodologies have many books covering this topic. The main issue is getting to the point where we can have these meetings, and again, I think this is where Scrum’s recommended approach is more manageable, especially for smaller organizations with limited resources.

Distributed team models are one of the topics lacking in the current Scrum literature. There are many ideas but not many proven answers. Project Management has addressed this only from a high level but much more so than the Scrum community. Distributed models can work in the Scrum environment; it’s just a matter of how you structure your teams. Although many believe that co-located teams are required to make Scrum work, this logic is fundamentally flawed.. For instance, even the first iPhone had a distributed team and we’ve all heard about the level of secrecy that Apple keeps on its development. To have a distributed team, we just need to employ a different set of tools. Several reliable and proven collaboration tools exist that bridges the gap between distributed teams and make things much more manageable than they were a few years ago. We can share documents, code, even the same workspace with the right applications. Distance should not be an issue, regardless of the team(s) utilizing Scrum or Project Management methods.

The limitations of either approach in the software development environment are well documented and can be found with a simple Google search. While neither on their own can address each limitation fully, I think we can see that when we start taking different tools and practices from each methodology we can address many of these issues. This is where I believe the next evolution in the software development environment will take place. The blending of proven Scrum and Project Management methods available today can not only move us beyond these limitations, but also make our projects nimbler, cheaper and “lighter-weight” than ever before thus getting our products to market faster, cheaper and with higher quality. Who wouldn’t want that?

Don’t forget to leave your comments below.

Don’t you Dare Play it SAFe

Written by Robert Galen on May 8, 2013. Posted in Articles. 13 Comments on Don’t you Dare Play it SAFe

Beware heavyweight software development frameworks that kowtow to status quo leadership practices

galen May8 I remember my first introduction to the Rational Unified Process (RUP) as if it was yesterday. I had a tremendous amount of experience with a wide variety of traditional Waterfall methods. Each promised to solve nearly every challenge associated with software projects and each failed to do so. So I was eager to try something new with RUP and was hopeful that it would help improve my software project success.

And as part of RUP I’m including the Unified Modeling Language (UML) and Use Cases as the defacto requirement artifact. There were a lot of new approaches within the RUP. It was sold as a ‘framework’; one with lots and lots of expert guidance. I think one of the overwhelming or inherent assumptions in RUP was that we (the customer of the process) lacked the ability to define an effective process.

So, RUP solved that problem. It provided templates, guidelines, phases, techniques, iterations, gates, hand-offs, planning guidance, testing guidance, models, workflow advice, etc. Literally thousands of pages of guidance for how to define requirements, plan, construct, test, manage, and deploy a software project. It was an amazing amount of “stuff”.

But interestingly, RUP did very little at the team level. It put a tremendous amount of information “out there” for the organization to leverage in controlling software development. But then it assumed that the execution was relatively straightforward. I.e., we’ve provided all of this sound expert advice, now the simple part is just following our guidance and you (the developers, the project) will naturally receive “great results”.

It always seemed to me that it was an iterative variant of Waterfall with some new requirement and modeling tools thrown in. Not bad really, but in my experience it didn’t result in successful projects any more than Waterfall did. And it didn’t seem to last that long either.

Agility and the Scrum Framework

Scrum is characterized as a framework too . But it’s much, much lighter weight than RUP was. The Scrum Guide, one of the definitions of Scrum, is a mere 16 pages long. I can deliver a well-rounded introduction to Scrum in about 90 minutes. I can get a team running their first sprint in about a day; the key requirement being whether they have a clear backlog of work to begin sprinting.

When I think of Scrum I think of a generic set of guidance (roles, artifacts, ceremonies, and practices) that surrounds how we build software. Yes, there are some rules and recommendations, but they are essentially in place to create and foster an environment of collaborative software development. Here are the 5 Core Scrum Values from the Agile Atlas:

Focus
Courage
Openness
Commitment
Respect

The Agile Atlas defines “Core Scrum” succinctly and is probably even shorter than the Scrum Guide.

The other reaction I have to Scrum is that it’s not “for” the leadership or organization. What I mean by that is that the prime focus is team-ward first and organizational second. Let me use a concrete example. There are no PMO project status reports dictated by Scrum. No organizational level data gathering. No stop light (green-yellow-red) reports.

If a project manager or functional manager wants to know how a project is going, they need to engage the team. Attend the daily stand-up and the sprint review and find out what’s going on, what the team has delivered, and what part they can play in helping the team be more successful. Asking themselves – how can they “serve” the team over how the team can “serve” them?

The Scrum framework provides “just enough” guidance and then asks or requires the team and organization to “fill in the blanks” by applying a customer value and lean mindset.

It’s simple. It’s clear. And it fosters collaboration around providing valuable “stuff” to our customers. Yes, I’m a bit biased towards agility and Scrum. But I’ve found that having a very lightweight framework and then engaging the team in extending it for their context and situation and domain and customers is a much better way to be successful.

Not let’s shift the focus towards another, perhaps a bit beefier framework.

The Scaled Agile Framework – SAFe

The other evening I attended a talk at the ALN – Raleigh group presented by Dean Leffingwell. It was sponsored by Rally Software and held at their Raleigh office. Try saying the Rally Raleigh office three times quickly…but I digress.

I’d been reading about and studying Dean’s Scaled Agile Framework or SAFe for quite some time. It’s becoming a popular topic in the agile community as it slowly gains traction. Rally is a strong supporter of it. Part of that is their longer term relationship with Dean as an agile thought-leader and advisor to their company. Another part of it is clearly their products’ evolution towards a 3-tiered Agile ALM model and the alignment between their tools implementation and the SAFe framework.

Dean mentioned in the talk that an early adopter of SAFe was John Deere and that he and Rally deployed much of SAFe in the coaching and tooling implementation at Deere; so there is a bit of mutual business interest driving their collaboration as well.

Anyway, Dean was kind enough to go through SAFe in a talk he entitled: Know the Way, Show the Way, Go the Way: Scaling Agile Development. While the title sounds quite generic, the session was focused entirely on the Scaled Agile Framework.

What I like about SAFe

There seem to be quite a few 3-tiered models cropping up that seem to be useful in adopting agile at the Enterprise or larger-scale levels. The tiers often have Kanban practices in the upper two tiers and Scrum at the team or execution tier. That generative model seems to work quite nicely in funneling work from high level product roadmaps, through early feature validation, down towards team(s) implementing and delivering valuable releases for customers.

Mike Cottmeyer has been discussing these sorts of models, probably for longer than Dean has been discussing SAFe. There are a few connections to Mikes work in the references. And Alan Shalloway seems to have hitched his wagon to Dean and SAFe too for enterprise-level adoptions; and he’s talked around similar models with an emphasis on Lean at the Enterprise in his NetObjectives webinars.

Point is – this sort of structure and funneling of work through a 3-tiered model can be a constructive way to attack agile within the Agile Enterprise. SAFe has to-date just done a better job of documenting and marketing it than any other model .

Another useful aspect is simply the terminology. For example, Dean introduced the notion of an Agile Release Train in his two books . I’ve found that model to be an incredibly useful concept for deploying Scrum and other methods at-scale in organizations. It extends the basic, deliver at the end of each sprint model, for contexts where that is impossible for a variety of reasons. It introduces concepts like: sprint synchronization, hardening or stabilization sprints, and fosters release-level planning.

All of which I think are missing in many organizations implementing agility at-scale.

So the terminology, 3-tiered model and even some of the smaller models within each layer are quite relevant and helpful in at-scale agile instances. So if everything is good, where’s my concern?

But more importantly, what frightens me about SAFe?

In all of my research around SAFe and in the presentation the other evening, I get the overall impression that it’s an exhaustive and detailed framework. It also seems to have a primary audience. It seems to be primarily “for”:

the Senior Leaders; Stakeholders
the PMO; the Project Managers
the Accountants
the Managers
the Architects and upfront designers
the planners
the formal process designers, ex: CMMi, ITIL
the regulators; the quality checkers

The intent seems to be to wrap up this “agile team stuff” in a way that can be easily understood. In a way that can be managed, reported, and measured the way things have traditionally been managed, reported, and measured. In other words, SAFe seems to be a framework map that fosters very little organizational level change when moving to agile methods.

I can see why the above listed folks are so excited about SAFe…particularly in at-scale scenarios. But I worry that something is getting lost in SAFe; something important, something critical to the success of agility.

What might that be you ask?

The People

The Creativity, Adaptability, Innovation, Empowerment, Engagement, Courage, Transparency, and the Energy Surrounding the Team

It’s about the Teams…stupid!

First, there seems to be a de-emphasis on the team and an emphasis on the organization. I’ll explain it by sharing a story Dean told in our session.

He was referencing a 10 team instance of agile. The teams worked hard and scheduled ten sprint reviews at the end of their efforts. Stakeholders and managers dutifully attend the first round of ten meetings. Then they go away.

He asked – how many of them will return for the next of sprint reviews? The implication was that they clearly couldn’t spend their valuable time iteratively reviewing all ten teams work. He implied that in the “real world” these folks simply didn’t have the time for it and it wasn’t sustainable.

Rather, the teams needed to roll up their results into a singular demonstration event much closer to or right before the release. Call it a release review. This way, the time of the stakeholders and leaders would be effectively honored. And the team would get the benefit of demonstrating more mature software and gaining broader feedback and visibility.

I say phooey to this notion or mentality that the leader’s time is most valuable; that the team inherently needs to “serve” the leader. If the team is working on the highest business priority work on the planet, the premise of all agile teams, then as a leader I need to get out of my chair and go engage with the teams. I should passionately care about what they’re doing, how they’re doing it, and what it looks like.

Getting to a sprint review, reviewing the work we’re delivering for our customers, should be my prime directive.

Now certainly, at-scale, the teams could and should consolidate their results so that the review is crisp, integrated, relevant, and time sensitive. BUT, organizational leaders should view it as a responsibility to attend, engage and learn.

The exception I take from Dean’s story is that it clearly supported the mindset that the team was serving the leadership. And that their time was more valuable focused elsewhere. Yes, their time is valuable, but there is nothing more valuable than them providing vision, interaction, engagement, and INTEREST in their teams’ efforts to delight their customers.

It seems to me that Dean and SAFe are potentially reinforcing traditional, command-and-control, hierarchical management and leadership. Or at least that’s my overall impression AND my primary concern.

Sidebar

I thought it might make sense to provide an example of the level or prescriptiveness that SAFe provides at the lowest possible levels. Under the PSI/Release Objectives Abstract advice, SAFe recommends the use of “Stretch Objectives”.

To the best of my knowledge, nobody in the agile community is recommending this notion. Now in my coaching, I personally like mentioning the notion of “stretching” in meeting sprint goals. Heck, I even talk about planning sprint stories as part of sprint planning. However, that is situational in nature and under my direct coaching guidance – so that teams understand the nuance and don’t over commit to too much work.

However, I think it quite dangerous for SAFe to make this recommendation. It’s not that it’s inherently bad. It’s just that there is an incredible amount of room for organizations to misinterpret and wrongly implement this sort of advice. In this example, requiring agile teams to “stretch” under all circumstances because SAFe supports the notion.

It begs the question as to whether Safe is truly “safe” without expert and situational coaching at a team, program, and organizational level?

I for one don’t think so…

Wrapping Up

You may be asking yourself why I brought RUP up in the beginning of the article. First, it is a useful anti-pattern example for heavier weight frameworks. But that wasn’t the primary driver. I see many similarities between RUP and SAFe. It actually starts at the roots of them both. Dean was an influential figure within the historical RUP community. At one point he created a company that developed a heavyweight requirements management tool – Requisite Pro. That company was then acquired by Rational; yes, the “Rational” in the Rational Unified Process. From 1997 – 2000 he was a Sr. VP at Rational Software Corporation; right up to and post the acquisition by IBM.

So, I think he has a tendency to think in terms of these all-encompassing, detailed, prescriptive processes. That’s not necessarily bad. But you have to ask yourself is SAFe driven from a true understanding of agile principles and practices upward OR is it a modification of RUP thinking over top of the agile methods. I actually think it’s the latter. Dressed up with a lot of lean terminology to make things confusing and perhaps more palatable.

Conversely, I think Mike Cottmeyer came to a 3-tiered model from the bottom up. That is, having a full empathy for and understanding of the team, before connecting agility to the organization by developing aspects of a 3-tiered framework.

So, is SAFe inherently bad? No, I believe it has the potential to be an effective model. But what I want to see in the forefront of SAFe’s focus are these tenants:

A focus on the agile team
A focus on organizational transformation
A focus on leadership transformation
Less prescription of detailed practices and much lighter weight guidance, which honors context-based practices
An acknowledgement that it’s about the organization serving the team rather than the team serving the organization

Oh and BTW, let’s stop the certification insanity that surrounds SAFe. If Dean is going to put it into the public domain, then do so. But don’t then turn around and wrap a 3-tiered certification model around it to create control of the implementations and drive a business model. I don’t think you can have it both ways.

As an aside, I wish more folks would adopt the example that XP provided. While it’s one of the agile methods, there’s never been much prescriptiveness around the definition nor efforts to control it by certification. I admire Kent and the XP community from this perspective.

So as the sergeant in one of my all-time favorite TV shows (Hill Street Blues) often said: Let’s be careful out there…in our use of SAFe!

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

References
1. Here are several of Mike Cottmeyer presentations surrounding at-scale recommendations for agile organizations:
a. http://www.slideshare.net/mcottmeyer/pmi-atlanta-agile-lig-enterprise-agile
b. http://www.slideshare.net/mcottmeyer/exploring-agile-transformation-and-scaling-patterns
c. http://www.slideshare.net/mcottmeyer/scrum-and-kanban-in-the-enterprise-webinar
2. Disciplined Agile Delivery (DAD) is another SAFe-like framework being put forth by Scott Ambler. It’s somewhat less prescriptive than SAFe and worth a look here: http://disciplinedagiledelivery.com/
3. While I didn’t mention them in the article, Bas Vodde and Craig Larman have written two books that are very much aligned with many of the SAFe and DAD oriented principles. They focused on Agile at-scale. More info here: http://www.craiglarman.com
4. And another book jumping on the SAFe, more robust framework bandwagon: http://scaledagileframework.com/new-agile-book-with-safe-valpak-case-study/

Use Sociocracy to Scale Agile Organizationally

Written by Derwyn Harris on April 17, 2013. Posted in Articles. 9 Comments on Use Sociocracy to Scale Agile Organizationally

We are at an important juncture in the evolution of product delivery. Agile methodologies have lost sight of some of the core values, and not enough people are using social technology to fully realize Agile’s potential.

Agile, once hailed as the answer to development woes, has become a source of contention and debate. Organizations with larger, more complex projects struggle to adopt Agile. Some organizations won’t even try due to formal processes designed to ensure the projects meet regulations, follow contracts and avoid costly mistakes. This is especially true in industries where the final product includes hardware that can’t easily be built iteratively.

Despite these concerns, isolated teams within organizations continue to implement Agile where possible. This inevitably is worse because it creates a disconnect between the teams operating within Agile and the rest of the organization.

A lot of these issues are because Agile methodologies are designed around small-team, single-location, software-specific constraints such as sticky notes, standups, and iterative working software. Because of these constraints, Agile methodologies continue to fall short, failing to extend sufficiently beyond engineering to include the wide range of stakeholders impacted by product delivery within the organization.

There are solutions to these issues, one of which is a concept called sociocracy. The primary problem stated above is that communication is isolated to the specific teams using Agile. Lines of communications necessary for change to occur, and for decisions to be made, are not efficient enough within traditional corporate hierarchies. Sociocracy provides organizations the ability to streamline channels of communication by creating overlapping “circles” and “double-linking.” Circles are groups solely responsibility for a goal, such as a sprint. Double-linking ensures that representatives in each overlapping circle are present. This is not simply having a manager present in one circle to listen in. Double-linking ensures that communications and decisions are relayed quickly, without losing information or causing confusion. This becomes increasingly powerful as you look beyond the traditional product team to include other groups, such as sales, marketing or external stakeholders that before felt excluded from the decision process.

A good exercise is to write down each perceived circle within your organization. This could be any group with a specific set of goals, such as an engineering team responsible for a sprint, or the company board of directors.

Next, connect how they communicate and determine who represents the double-linking. Chances are you will find either a single person who is acting as a single-link in many circles, or no direct overlap at all. This is where the communication breakdown begins and is the primary reason why Agile fails. This problem is exponential as the size of the organization or complexity of the product increases.

In summary, sociocracy is a system designed to incorporate the principles of agile (collaboration and interaction) on a much broader scale. This will ultimately help organizations become more nimble by focusing on the lines of communication rather than on methodologies that don’t scale.

Don’t forget to leave your comments below.

The Agile Project Manager: Core Scrum Values & Courage

Written by Robert Galen on April 3, 2013. Posted in Articles. 10 Comments on The Agile Project Manager: Core Scrum Values & Courage

The five Core Scrum Values have been defined as:

1. 1. Commitment
  2. Openness
  3. Focus
  4. Respect
  5. Courage

My references for this list include a blog post by Mike Vizdos, and the Scrum Alliance site where you can see them articulated.

Tobias Mayer wrote a counterpoint blog post on these values and suggested a different set and focus all on his own. Here’s what Tobias had to say:

I believe there are some core values, that can help establish a way of being that offers a foundation for success in moving from a left-brain, logical, commanding culture, to a right-brain, intuitive, creative one. Each of these values begins within self, and can be lived independently of the reactions of others.

1. Courage — seek your edge; speak from your heart
2. Trust — lead from a place of faith, not suspicion; follow likewise
3. Congruency — act with integrity, so your actions and your feelings are always in alignment
4. Humility — acknowledge your uniqueness, celebrate your strengths, yet strive to be a worker amongst workers
5. Service — Be alert to the needs of others; ask for and offer help in equal proportion, for service is in the receiving as much as in the giving

Through making a conscious, personal decision to live by these values, healthy community emerges. And when we have a healthy community we stand a chance.

I like the fact that Tobias takes a different view towards the values. His lens seems to be one that is more personally focused towards the agile practitioner or coach. So, I thought sharing the contrast would be helpful. But truly I want to focus in on the one common attribute in both lists—courage.

Focusing in on…Courage

Galen IMG02 April3 I remember when I received my Scrum Master certification (CSM) in 2004 from Ken Schwaber. I’d been practicing Scrum for a while, since probably 2000-2001, and I wanted to gain some lessons from the “Father of Scrum”. So I flew to Chicago for a CSM class he was co-teaching.

I remember at the end of the first day, not being ‘wowed’ by the material and wisdom. I had truly not learned anything new and I was disappointed. I looked forward to the second day with anticipation—surely there would be something shared that was agile and wise and powerful.

At the end of the last day, the lessons were better than the first day, but I still felt disappointed. However, there was one breakout that was thoughtful, powerful, and made me think quite a bit.

It was a software project simulation about providing a ticketing system for Major League Baseball. The way it was written, Ken explained afterwards, was to articulate a Death March project; one that should be politely but firmly declined because of the lack of feasibility. However it turned out that very few class groups/attendees would ever actually say ‘No’ to the project. Instead, they would fall into a familiar pattern of problem solving, can-do behavior, and basically tell management what they wanted to hear: Yes, we can do this project.

One of the major points of the exercise was to test, what I’ll refer to as your courage, particularly if you were an aspiring Scrum Master. Did you have the courage to tell stakeholders the truth? Did you have the courage to steer your teams away from over-committing and underestimating? Did you have the courage to take a professional risk? Could you overcome our tendency to please our leaders and filter less? And finally, gulp, could you ultimately say “NO” to a project?

I followed the results of this exercise as it was given over and over again to early CSM classes. I remember Ken sharing that the failure rate, i.e. groups that would agree and commit to the project was around 96-98% of all attendees. The hope was for the groups and individuals to actually decline by this amount because of the way the scenario was written.

Put another way: You have a project that, due to the way it’s envisioned, constrained, and instantiated, inevitably will be a Death March. It will clearly fail. Yet, over 95% of the folks who review it want to sign-up and take a ‘whack’ at it. Imagine that!

When I think of this scenario, I refer to it as a Myers Briggs test of our inability to say no or challenge our leaders when given very, very challenging software projects. It seems to be in our DNA as technologists and employees.

So what are the aspects of “Courage” in software projects?

It’s hard to define courage because it’s so situational in the contexts I’m referring to. I’ll share some of the following aspects, knowing that the list is not exhaustive:

Telling Truth – Say what’s on your mind more often. If a teammate is delivering poor software, tell them. If your boss is asking for more than your team is capable of without compromising quality, tell them. If you can’t meet some arbitrary date commitment, tell your customers so. Be bold, filter less, and tell more truth.
Defending the Team – If you’re in a leadership position, instead of being responsible for strong-arming your team into saying yes, support and defend them. Be aware of their capability and push back when they are being asked to do more than is possible, feasible or wise. Be aware of technical teams’ tendencies to over-commit, so defend them from themselves as well.
Know Thyself – Understand your strengths and weaknesses; leveraging your strengths and depending on your team to offset your weaknesses. Ask for help when you need it. If you don’t know how to do something, say: I don’t know. Then accept the advice and help of others. If you have a tendency to over-commit, realize it and ensure you have others who are more cautious and realistic around you.
Be a Realist – At our heart, software folks are optimists and problem solvers. We love a good problem; the harder the better and we always think we can solve everything. It’s easy to say yes to everything or to take on all projects or to say you can do something you’ve never done before. It takes courage to tell truth and be more of a realist. Not every problem is solvable as presented to us and we need to realistically assess each “opportunity”. Don’t be afraid to be the lone voice telling truth.
Be willing to Walk Away – This is particularly true for leaders. You have to be willing to stand on your principles. If you get the inevitable management pressure to do something that you know won’t turn out well, you always have a choice. You can acquiesce to leadership and on your principles OR you can walk away. While it may be frightful, sometimes walking away is the most congruent, honest, and best response to a Death March project.

Wrapping Up

One of the common stories that came from students going through Ken’s scenario is that management threatens them. Some of them have been threatened with assignment to less than ideal projects and others with demotion to lesser roles. Still others have leaders who lose all subtlety and simply threaten to fire the team if they don’t take on the “opportunity”, ahem, I mean Death March.

Some of them also recount another strategy; one based on competition. Years ago IBM was notorious in starting two or three teams on the same project. They would let the teams “duke it out” to see who won. I guess it was nice to have so much cash on hand that you could take that approach. More recently, offshore teams are a competitive threat and, depending on the cultural dynamic, management will never see courage from them.

But no matter how you slice it, projects need to be setup for success and your leadership needs to listen to their teams. Have the courage to work hard, be cautiously optimistic, be a truth teller, and deliver great results. And if necessary, occasionally you might need to “vote with your feet”.

Thanks for listening,
Bob.

Don’t forget to leave your comments below.

The term Death March was first articulate and described by Ed Yourdon in his similarly titled book. The book details the insidious dynamics of some software projects that are doomed from the start, but still manage to garner a sponsor who is unwilling to accept defeat.

Getting Buy-In and Engagement For New Requirements-Management Environments

Written by Derwyn Harris on January 16, 2013. Posted in Articles. 8 Comments on Getting Buy-In and Engagement For New Requirements-Management Environments

To effect change, market a process not as something new, but as something everyone is doing already. Whether your organization follows the organic or top-down approach, appeal to human nature to drive adoption of new processes and tools.

In a recent webinar on elements of successful requirements management, one of the attendees asked a question I hear all the time: “How do you get people to buy-in and participate, actively collaborate, in a new RM environment?”

Essentially, when it comes to adopting new processes or tools, how can one help effect change in an organization? Individuals take time to learn best practices—they attend webinars, read books and articles—and get inspired to apply them at work.

Then they face the daunting task of getting the new thing adopted. Sad to say, change is ultimately a difficult task made even more difficult by human nature. People resist change, especially within the corporate world.

Traditionally, change can be accomplished in two ways.

The first is the ground-up, or organic, approach, in which an individual evangelizes and implements a solution for the team. This has distinct advantages because it can be more controlled and ultimately more focused. However, this process can result in cross-department conflicts or disenfranchisement by people not part of the process but who are directly impacted by the change. The resulting confusion can bring more harm to the organization as a whole, than the gains realized by the small group.

The alternate approach is a more top-down approach, wherein a corporate directive (with numerous committees and meetings) is set to standardize on a process or toolset. The advantages here are clear: providing an alignment between teams or departments. Of course, there are also issues. Selecting a universal approach or tool potentially disenfranchises large groups of people who were not part of the decision process or simply find themselves required to do more work than before in order to incorporate the new process (even when there are clear gains from doing so). Word documents are a perfect example. Although a document is by far the simplest tool for capturing written information, the long-term impact of multiple documents (organizing, updating, collaborating on, extracting information from) can be costly. Moving to a new solution may require additional time for entry, but the broader perspective is a positive gain.

So, both approaches have advantages and disadvantages. Neither is that effective.

So what can be done to improve the success of process change? Again let’s embrace an equally basic truth about human nature. Humans inherently desire to feel connected. They also desire to have that shiny new object.

A recent article in the Boston Globe describes how to effect change.

The two quotes that caught my eye:

“To really change how a group of people thinks and behaves, it turns out, you don’t need to change what’s inside of them, or appeal to their inner sense of virtue. You just have to convince them that everybody else is doing it.”
“The pressure to conform to what is typical … tends to be stronger than the pressure to follow top-down rules.”

With this in mind, market the change not as something new, but as something that everyone is doing already. Do this whether your organization follows the organic or the top-down approach.

Once you consider the early adopters, and the shiny-new-object factor, effecting change becomes simply a matter of tapping into that cool factor that makes things more interesting. When selecting a new tool, consider the user interface, intuitiveness and the cool factor as part of the decision process. These attributes will draw people in naturally and create the necessary groundswell for widespread adoption.

It will help to work with marketing or management to alert the organization that teams are being successful with change and others should follow.

In summary, change will not be truly accomplished with force, regardless of the approach. Human nature is part of the process, and we work better when we feel that our work is enjoyable and when we are connected with our coworkers.

Don’t forget to leave your comments below.