Waterfall, Agile, and Organizational Focus

A colleague asked me the following question, which I thought was great and could be helpful to others to discuss.

Question: "Many of our IT projects use a project management style that is more Waterfall than not. This creates all the problems associated with a Waterfall process, such as very long delivery times and poor fit for requirements.

Some attempts have been made at introducing an Agile methodology. The most common reason these didn't work out seems to be that cross-functional teams compete with the regular/operational work duties of team members. People claim they aren’t able to attend meetings.

When multiple members are regularly not coming to meetings, the results are predictable: frustration, failure to meet deadlines, poorer deliverables. The end result seems to be a return to a Waterfall approach that silos stakeholders, PMs, and developers.

Is there a best practice way of dealing with what must be a common occurrence?"

Response: In my career the "best practice" response I've seen to this has been something like:

• Commit the organization to growing a Lean/Agile approach over time
• Hire a Lean/Agile coach to provide thorough training and coach some teams in Agile practices
• Use a continuous improvement cycle to help the initial teams improve while spreading the approach to more teams

I work in an IT organization where that approach was started over five years ago. I would say success is very mixed. On the plus side, Agile has stuck around, and the teams using it seem happy with the control and flexibility it gives them. Ongoing challenges in my organization are similar to what my colleague describes in his:

• Difficulty creating and meeting estimates for long-term work
• Difficulty keeping up with business priorities
• Difficulty getting business participation in the Product Owner role

What would be a standard "best practice" followup? Something along the lines of: do more training and coaching. Help teams improve their practices. Start smaller, demonstrate success, then grow the new practices.

Those are reasonable tactics, but I think there might be organizational root causes to consider as well. I think it has to do with the organization's basic ability to truly commit to Lean.

A basic tactic of Lean is to identify and eliminate instances of waste. A basic form of waste is work in progress. One way this this translates into IT is trying to do too many things at once compared to the resources available. (Another way to say this is that Lean is about respecting individuals, which includes enabling them to do their best work.)

Inability to focus and retain resources on top priorities is a problem that spans Waterfall and Agile approaches. Lack or loss of resources is a classic "top ten" reason for project failure in traditional project management. Another example: most organizations can name "bottleneck" resources who are clearly overloaded and (unwillingly) put outcomes at risk. And in Agile, because of the emphasis on continuous teamwork, it becomes especially apparent which individuals have too many competing duties.

From what I've seen and read, success with Lean and Agile requires a leap of faith. The organization's leaders, customers, and teams must truly believe that in the long run, focusing resources is better because:

• Completing a few high priority outcomes sooner (and moving on to the next ones) is more valuable than making slow progress on numerous competing priorities (and falling short in most)
• People are more productive when they do less switching between jobs, so total productivity increases
• Quality increases when people have enough focus to improve how they work

The value proposition is straightforward, but the reality for organizations is quite difficult. That's where it's important to be honest about the organization's ability to commit. Can the organization truly:

• Make and stick to a long-term commitment that affects everyone -- are there relevant examples of doing this?
• Ensure that decision-makers prioritize some goals and defer others -- when their success so far has been based on appearing to satisfy or appease everyone?
• Bring along everyone who will be impacted -- not just implementation teams but also operations and the customer?
• Push through a difficult learning process, a lot of contentious tradeoffs, and an initial apparent reduction in productivity to get to the benefits of a new way of working?

If we're being honest, I suspect the correct answer in many organizations is: no, not yet. In their book The Toyota Way to Service Excellence, Liker and Ross reflect that in most organizations Lean transformation will fizzle out or turn into a set of formulaic, low-value tools. The basic premises of focus and respect for people don't fit how those organizations define success in their culture.

What this suggests to me is looking for opportunities to shift an organization's culture over time and strengthen "muscles" over time.

One opportunity, as old-fashioned as it may seem, is to get better at Waterfall -- because many of the same muscles will help strengthen Agile teams later. For example:

• Improve resource tracking to provide better information about how many and which projects can realistically be done
• Improve project prioritization to ensure the most important projects get the most attention
• Proactively identify and resolve resource contentions
• Improve estimation and tracking of projects to provide a "feedback loop" for resource management and prioritization
• Improve communication with stakeholders to demonstrate where progress is being made and why other goals are being deferred

For IT organizations, the cloud and DevOps offer another kind of opportunity at the moment, because they shift how resources are used and how teams work. If teams for new services can be encapsulated and grown with limited dependency on existing operations, and those services can maintain focus, then gradually the culture of an organization can change as other services fall away. Of course, that's a long game with serious management commitment and risk.

What other opportunities have people seen work to overcome barriers to organizational focus in either Agile or Waterfall? I'd love to see your comments.

Maker - A Missing CliftonStrength?

I've benefited from using Clifton's StrengthsFinder method for myself and teams, and I recommend it to people who are thinking about their jobs and careers. I think the method contributes to opening up important internal and team conversations.

Nevertheless, every time I've taken the assessment and looked at my personal strengths, I've felt something missing. So I'd like to propose an additional CliftonStrengths theme that I think will resonate with others to, from what I've seen at work and in my hobbies.

Maker 

You have a natural drive to make things. What you want to make may vary -- for example, it could be a physical object, a piece of writing or software, a team, an organization, or a process. You find great satisfaction in making, which can include evaluating ideas for new things, planning how to make something, designing it, collecting inputs for it, the process and craft of making it, finishing it, sharing it with others, and observing how it is used. You probably experience making as a "flow state." After making something you feel a sense of achievement from materializing an idea, but also soon want to go on to make the next thing. The thing that was made is only partly an end in itself; the desire to make is a flywheel that keeps you going from one project to the next.

To others, the opportunity that you see to make something may not appear as valuable as it seems to you, because of how you value the act of making and the intrinsic value of the thing to be made. To your team, making something may seem merely necessary or incidental to achieving an outcome. Others might see something as "good enough" and ready to use or set aside while you still see many opportunities to improve it. 

You may find it helpful to partner with others who are focused on engaging people in the work, or as a source of ideas, or to help apply and realize the value of what was made. Using your Maker strength, you can help others execute on their ideas; they can experience a sense of participation in the result. As a leader, you can share the excitement of making something bigger together. If you work with or manage Makers, help ensure they have something to make and guide their energy toward the most valuable outcome for the team.

In thinking about this theme, I wondered why it is not already included in StrengthsFinder. I suspect it is because Donald Clifton was interested in "soft skills" that were -- and often still are -- under-recognized or undervalued in the workplace. From this perspective, making is associated more with the "hard skills" involved in a specific discipline or craft.

However, I'm pretty confident that some people are more driven Makers than others, and that the drive to make has important implications for how someone looks for opportunities, participates in a team, and gains satisfaction from their work. For example, when I reflect on and journal my own work, along with appreciating how I've helped others, I list specific things I've made as personal milestones.

With our contemporary emphasis on teams, soft skills, value, and so forth, sometimes the joy of making something, and the discovery and unexpected value that can result, can take a back seat. I've even felt guilty about proposing to make something because it seems "tactical" and not "strategic" to do so. Of course I would agree that the team and the outcomes are ultimately more important; making good use of the Makers in your team is one way to support that.

Regarding existing themes in StrengthsFinder, I see some overlap with Activator, but with the emphasis on a specific thing to be made over generally "making things happen." Related strengths could be Achiever (motivated by working on something defined), Focus (following through on the vision for something), and Intellection (thinking about something for its own sake).

Is Maker a theme you identify with too? Does this definition seem like it closes a gap in StrengthsFinder for you? I'd be curious to hear. Thanks for reading!

Reflections on Growing a Business Analysis Community of Practice

Since 2014 I've helped grow our organization's Business Analysis Community of Practice. Today this active CoP brings together practitioners and practices from all over our university. The CoP:

• Creates a place for new practitioners to feel welcomed and meet others doing similar work
• Enables practitioners to build each other's knowledge of best practices and business domains throughout the university 
• Helps practitioners converge on shared methods, making it easier for teams to get started and share informations
• Helps practitioners understand business analysis career paths and retain great people in the organization

If you don't already do something like this in your organization, I really encourage you to try it! Here are my reflections and lessons learned.

The early days: peer networking

The CoP was founded around 2012 by Colleen Kelly, a business analyst in central IT at the time. It started as an invitation to meet once a month in the cafeteria for afternoon coffee. Colleen used her network to reach out to peers, word got around, and by the time I joined in 2014 there was a core group of five to ten "regulars." We met to chat, network, and hear about each other's projects.

Just a few simple tools helped the group get started: a mailing list that anyone could join, and an internal web page with basic meeting information. The CoP also benefited from the work of our fantastic Organizational Development team in central IT, which promoted the concept of CoPs and regularly brings together the volunteer CoP leaders to exchange their experiences. (You can find all the CoPs that this great work has resulted in on this site.)

In retrospect I think some key aspects of this phase were:

• Concept of the CoP -- some organizational encouragement for practitioners to get together
• Someone to take the lead -- it only takes one volunteer to get the ball rolling
• Open community -- anyone could come for a friendly chat regardless of their level of experience
• Low threshold of participation -- no expectation for anyone to prepare content

Evolution to topical sessions

As a new business analyst at the university I had a strong interest in hearing about and sharing business analysis best practices. I found other CoP members were interested in this too, though we also found that we all had slightly different roles, approaching business analysis from different directions.

To dig into this we started to alternate a few of the networking sessions with topical meetings. A few members shared projects they were working on, and we had a few sessions on general business analysis concepts. We found that this led to a new level of interest and new participants. Practitioners like to hear about each other's work and learn about different parts of the organization. But it was also very important to keep the informal networking going.

Hiatus, restart, and broader reach & leadership

During these years the CoP also had a hiatus. Colleen and I were co-leading and we both had job changes. There were no CoP meetings for a year or more. I mention this to point out that a  CoP can go through some fits and starts because it may rely on just a few people to keep momentum.

But it can also come back! In late 2017 I had a new role and time to start the CoP again. I joined forces with Taryn Rex, another business analyst, and we reached out to everyone we knew across the university who might be interested, encouraging them to also reach out to others around them.

At this juncture we changed the name of the CoP from "Business Analyst" to "Business Analysis" Community of Practice. We knew that people at the university were doing business analysis in many different roles -- a few with a Business Analyst job title, but many more as project managers, service managers, program analysts, data analysts, financial analysts, and so on.

As new members joined the list we asked them to complete a short survey on their interests and level of experience. This greatly helped us understand the community. We also started to offer online participation (through Zoom) since the university has three campuses. The community grew to over 150 mailing list recipients across the university, with 15-25 members attending each session based on their interests.

The restart focused on introducing business analysis practices in a more structured way. For the initial session I gave a one-hour introduction to business analysis to level-set expectations. Monthly sessions going forward would be focused on a survey of methods, a particular method, or a prepared presentation of project work. (You can view the calendar of topics for 2017-2018.)

When Taryn was unable to continue as co-leader, I decided to form a larger group to co-lead. From the first few sessions there were some clearly very interested participants, and I was delighted to find peers to form a wonderfully engaged steering group (listed on this page in the CoP web site). The steering group meets monthly to guide the direction of the CoP, develop agendas, and identify speakers.

Key reflections here are:

• If you're leading, understand what motivates you -- what's going to sustain you in taking this extra responsibility?
• A community is best led by a community -- find others who are also motivated to keep it going
• Many people in your organization could be doing business analysis, from many different roles
• Use the network of everyone you know -- interested people are everywhere

Transition to shared practices

The interests of new members showed a top recurring theme of learning about the most common business analysis methods in our enterprise. As a steering group we thought the CoP could build on this by sharing our top methods and starting to converge on common practices. We tried the following experiment.

For two two-hour meetings, we ran workshops in which small teams of 3-4 worked on a selected business analysis method. Each team chose from a list of common general methods. Each team drafted a short document summarizing:

• Description: What is this method?
• Step by Step: How to go about it in 5-7 high level steps
• Benefits: What value to expect from the method
• When to Use
• References: Probably the most important part -- links to external resources as well as examples from people's work within our university

We found a volunteer editor for each method and turned the drafts into web pages. The result is the following resource in the CoP's web site:

• Business Analysis Methods

The content is a mix of viewpoints since it was drafted in groups. But I think that is the power of taking this step: it is truly a peer-to-peer resource. Within the community, this work is a source of pride, an excellent basis for future meetings, and a foundation for continuous improvement. And as a practitioner, when I meet with teams I can now say, "these are common practices identified by business analysis practitioners across the university, and we should consider them in this project."

(On a side note, by this point organizing the CoP and developing business analysis in the organization had become  part of my job description as a business architect on the Enterprise Architecture team. While this might not be essential for every CoP, it has been helpful to know that putting 5-10 hours a month into planning and running meetings and doing outreach is supported by my management.)

Some key things I learned from this have been:

• Ask people to contribute -- more than you expect will be glad to
• There is no "right" version of a business analysis method -- the best fit for the organization is probably to start from what people have already found works, and improve on that 

What the future might hold

Where are we headed with our CoP? The steering group has lots of ideas. Some potential areas on our list include:

• Linking up with related CoPs -- for example our organization also has CoPs for project management, testing, and Agile practitioners
• Our new Slack workspace -- how to encourage more ongoing peer-to-peer conversation
• Bringing back more networking time for people to just get to know each other
• Creating ongoing "new to business analysis at the UW" sessions
• A track focused on helping hiring managers define business analysis roles, recruit, interview, and retain
• Sessions more focused on particular professional subdomains within business analysis, such as operational business analysis, process improvement, facilitation, data analysis, financial analysis, etc.

In an enterprise as big and diverse as ours, the potential topics are endless!

What has your experience been with CoPs or similar efforts? Hope to hear from you in the comments.