Enterprise Organizational Structures Are Not Agile and Don’t Work

As soon as any large enterprise decides to implement agile development, they run right into organizational boundaries. They are likely to have siloed departments much like the following:

• Program Management
• Product Management
• User Experience Design
• Software Development
• Quality Engineering
• Publications
• Customer Support

None of these departments can build, deliver and support a software system alone. They need to work together, yet they have conflicting priorities and needs. They are also measured quite differently. None of them has total control of the final product so they are measured around their respective deliverables, not the end result.

The benefit of having dedicated product teams has been proven repeatedly across many industries and product categories. Any agile development approach requires a dedicated product team. Strategy, or in this case tactical implementation, has just collided with culture.

Many organizations respond to the inherent conflicts by creating a matrixed management structure whereby people are effectively loaned to a project. This makes sense if you can avoid the “too many cooks” problem. That is, each department manager wants to control her part of the solution. If five departments are involved, the project has five managers plus the Project Manager or Scrum Master. Sounds like a recipe for failure, right?

Try the Centers of Excellence Approach Instead

Organizations don’t matter. Results matter. Customers matter. Customers want great products and services. Rather than implementing yet another re-organization, try adding Centers of Excellence (CoE) instead.

A Center of Excellence is a group of people focused on the continuous improvement of a key business or technology area. The group can consist of dedicated, full-time members and/or part-time contributors. CoEs do three things:

1. Support: They are experts within their focus areas. They offer subject-matter experts to anyone needing assistance.
2. Guide: They have access to and knowledge of applicable standards, tools and techniques making them a resource for all project teams.
3. Educate: They disseminate knowledge, offer training assistance, and provide standard metrics to measure progress.

The current department managers are good candidates to create and drive the CoEs. They should focus on CoEs not products. Let the product teams make the product decisions.

Here are some examples of CoEs to get you thinking about how they may fit into your company:

• Team leadership (e.g. Project Managers and Scrum Masters)
• Product Ownership (e.g. Product Managers and marketing managers)
• User Experience Design (e.g. usability engineers)
• System Architecture (e.g. software architects)
• Information Management (e.g. database designers and administrators)
• Test Engineering (e.g. software quality engineers)
• Publications (e.g. technical writers, graphic designers)
• Business Analysis (e.g. experts in compliance, six sigma, ISO 9000, productivity, etc.)
• Program Management (e.g. senior business managers who can establish priorities and allocate staffing)

Clearly, this single blog post only scratches the surface of the organizational issues that impact enterprise agile development. Hopefully, this post will give you some ideas and generate some discussion within your company. If you have other suggestions related to these issues, I’d love to hear them.

Enterprise Agile Development and DevOps Cause Major Upheavals

The concept of DevOps is gaining traction within the IT departments of many companies. What is DevOps? It’s the idea of a cross-functional team composed of people from development and operations. The team develops the software and support the resulting software application and associated infrastructure.

The DevOps approach is popular with companies offering cloud-based software. These firms usually perform frequent software updates and need to have development and operations closely aligned. Even simple software defect repairs need to be deployed according to an agreed-upon plan and timeframe.

DevOps also helps when you have a complex platform built on many software components, either custom built or off-the-shelf. When you have web servers, application servers, databases and other supporting software components, there will be many software update cycles to manage.

DevOps is just the beginning.

The enterprise agility problem extends beyond development and operations. What about program management, user experience, product management, quality engineering, software distribution, user documentation, and customer support? It takes many people with many skills to launch and maintain enterprise software.

There are organizational and cultural barriers to implementing enterprise DevOps or any form of enterprise agile development. If you’re serious about being agile, you’ll have to face them.

Corporations have spent years refining their command-and-control structures. Agile development and delivery is different. All that existing structure won’t have to be tossed but it will need a major overhaul.

I wrote an article for the ToolsJournal called “10 Tips for Succeeding with Enterprise Agile Development” In a series of posts over the next few weeks, I’ll expand on the ideas presented there.

Enterprise agile development, including DevOps, will cause lots of upheaval. Most companies seem to attack it in a piecemeal fashion hoping that many small changes will get them to where they want to be. It won’t work. I hope this series of posts helps.

Think About Software Requirements in More Than One Dimension

Identifying software requirements without confusing business users.

The “user community” for your software project doesn’t know what they want, so how can you? Like it or not, you have to pull ideas out of their heads and move everyone toward a common goal. It’s not easy, but it’s not as tough as it sounds.

We know that many software projects fail and that insufficient requirements analysis is the most frequently cited cause. But think about this: Analysis requires collaboration. Developers tend to speak in terse, acronym-filled sentences. Business people tend to talk about their problems and issues. Neither side truly understands what the other is saying, leading to false expectations and broken promises. How can you possibly analyze requirements in this environment?

Software professionals argue that the business people don’t know what they want. That’s partially true. How can they be expected to know what technology can do for them? Advancements in the field occur so quickly that what was almost impossible yesterday is commonplace today. The business folks, in turn, argue that developers aren’t focused on their needs. True again! Too often, developers are overly focused on technology. Business people don’t care. Just give them a solution that works reliably!

So how do you cross this chasm and get to a common ground?

One long-standing approach is to create a massive requirements document and get all the major players to sign it. I’ll bet many of you have been there and done that. It doesn’t work! Such documents are impossible to fully comprehend and are subject to widespread misinterpretation even if you can get key players to take the time to read them. They’re also a nightmare to update as requirements evolve.

How about creating a monstrous spreadsheet with all the features listed, along with priorities and stakeholders? Have you done that, too? It doesn’t work either! Technical professionals tend to like this approach because the spreadsheet serves as a checklist for implementation. Unfortunately, most people have trouble piecing together discrete functions into a coherent software application. Thus, their expectations of the final result will be wildly different.

There’s a better way.

Instead of writing, get into a room together and talk about the problems to be solved. Don’t concentrate on getting every detail in writing. Focus on extracting ideas, issues and needs. Communicate!

For example, if business users say they want to store information in a database rather than on paper forms, uncover the reasons why. Are they running out of physical space to store forms? If so, perhaps all they really need to do is scan the forms to create image files and store those images on a file server.

Is the goal to continue filling out paper forms while simplifying searches for information in the future? This is a more complex problem requiring optical character recognition or online data entry with the results stored in a database.

Or, do they want to enter and circulate information electronically and eliminate paper forms entirely? This is the most complex problem, requiring extensive design sessions. Business processes will have to change, and some level of retraining will be needed.

Developers have a responsibility to educate and inform. Talk to the users about trade-offs. Show them the risks and complexity inherent in trying to do too much, too fast. And don’t forget about cost and time. There’s never enough of either.

Time to start drawing.

Move to the whiteboard and rough out a solution. Crude? Yes. Effective? You bet! As you begin to capture major ideas and process flows, start to prototype the user interface with whatever tools you have available.

If you’re good with HTML, a browser-based user interface can be created quickly and inexpensively. You might choose a GUI development tool or even a PowerPoint presentation. Regardless of the tool, the goal is to mock up the major functions of the software in such a way that everyone can see and touch the result. Now you have multidimensional requirements. These have much more value than thousands of one-dimensional words organized onto reams of paper.

The software team will have a model for starting the build process. This model can readily be turned into use cases or stories depending on the development approach being used.

Business workers don’t need the latest technology. They don’t care about standards wars or programming languages. They need software they can really use. Give it to them!

Build the Simplest Software That Solves the Business Problem

Agile software development and feature-driven development (FDD) have much in common. Many agile stories encompass features requested by the software stakeholders and end-users. Yet, staying focused on features and not system architecture can be hard to do.

Let’s discuss a simple example. Say your development team is asked to build a simple software application that enables a customer to select a PDF file from a predetermined list of available files and download the selection. In the future, the list may grow, more file types may be added, and we may want to restrict download privileges, but none of that matters right now.

How should you approach this challenge?

Most software developers would want to plan ahead. They might want to build a database to hold the PDF collection (or links to the PDFs). They’d want to implement a search function, capture and save user information, include links to PDF file viewers, add a front end for uploading new content, etc.

All of that may be needed in the future but the current request is much simpler – As a customer, I want to pick a PDF from a static list and download the file. Someone might argue that the software application is too simple to be realistic — that it has little, if any, practical value.

Consider these possibilities:

• The business may want to test the viability of offering customers electronic documentation in place of paper.
• The PDF files may be massive, over 20MB each, and customer acceptance needs to be tested.
• Demand for the files is forecasted to be high and the infrastructure capacity needs to be assessed.
• A large customer is demanding electronic documentation and it needs to be made available fast.
• The company is moving to a new software environment but can’t wait for it to be deployed. The download capability is needed now.

You get the idea. There are many valid reasons for wanting to offer a simple solution now while retaining the option to offer a much different solution later. The challenge is to keep the software team focused on the current target not future possibilities. That’s what feature-driven development is all about.

Clearly, if the initial idea proves viable, the simple solution depicted above will be largely tossed out and replaced with a database, a search function and some form of user identification. The business stakeholders and Product Owner need to recognize that the initial solution will need major refactoring to achieve enterprise scale.

This may seem wasteful but the alternative is to invest lots of time and effort building a robust solution that may not be needed by the business or wanted by the customers. An open dialog and close collaboration between development and the business are necessary to make this work effectively.

Here’s the bottom line.

If the business knows what they want and can justify it, take the time to lay a strong foundation and build on it incrementally. But if they aren’t certain and need time to evaluate and refine their ideas, build the simplest solution that delivers the features they specify and refactor as needed. That’s agile FDD!

It’s Time to Redefine the Scrum Role of Product Owner

Are we expecting too much from our Product Owners?

I’ve read many descriptions of the role and the responsibilities for a Product Owner in Scrum. Some of those descriptions seem over the top and appear to expect too much from the role.

Comments like “willing to make hard choices” (ScrumAlliance.org) and “the single person responsible for whether a project sinks or swims” (Top7Business.com) seem excessive. We pitch agile software development as a self-organizing, team activity. So, why do we accept the definition of a powerful, single-person role on Scrum projects?

These role descriptions border on omnipotent. When I read them, it makes me think that someone is being setup to be blamed if the project fails. We see these kind of omnipotent descriptions for many job opportunities on the Internet.

Anyone who is not perfect, need not apply. If you’re perfect and the project fails, we’ll blame you.

No thanks. I won’t be applying.

Product Owner responsibilities don’t boil down to telling the team to “do this” and “don’t do that”. It’s much more like “let’s try this” and “let’s not try that”. In other words, the Product Owner is not making final decisions. He is deciding what to present to the business stakeholders and/or the user community for evaluation.

The stakeholders and end-users will make the final decisions. The Product Owner is more of an ambassador — someone who guides everyone involved toward a final decision.

It’s important to note that the Scrum Master and the team members have an obligation to speak up and make themselves heard. The Product Owner may want to include a software feature that is simply not practical within the context of the current release cycle. It is important that the team speak up and equally important that the Product Owner listen.

Defining omnipotent roles doesn’t lend itself to the kind of give-and-take dialog needed on complex software projects.

In the end, the development team will succeed or fail as a group. The Product Owner plays an important part but so does the Scrum Master and each member of the software development team. Anyone who doesn’t do their part can bring down the entire team.

So the next time you’re looking for a Product Owner, focus on leadership and negotiating skills not decision-making. And one more thing, don’t go looking for someone to blame before the project has even begun.

The Daily Stand-Up: Start Time Doesn’t Matter

What time should your daily stand-up meeting be held?

The subject of what time to hold the daily stand-up is frequently asked by software development teams following an agile approach like Scrum, Kanban, Lean or XP. Most teams like to hold the stand-up ‘first thing in the morning’ — whatever that means. Here’s the problem.

Some people like to arrive at the office early — at times as early as 6:00am. Others like to arrive later, maybe much later. It’s not unusual to find people starting their day at 10:00am or 11:00am. By the time the latecomers arrive, the early risers are half way through their day.

If you schedule the stand-up meeting early in the morning, the latecomers will not be happy. Having your daily routine upended is never a good thing. We’re all creatures of habit.

If you schedule the meeting later in the day, some of the early risers may flounder. They may bide time until the stand-up begins, unsure of what to focus on for the day.

The situation becomes more complex if the team is distributed across time zones. Imagine someone in the eastern U.S. starting work at 6:00am local time while someone in the western U.S. starts at 10:00am local time. That’s 1:00pm in the east and the early risers will be heading home soon.

Redefine the cycle

The problem begins with the basic questions asked at the standup meeting — “What did you finish yesterday?” “What will you finish today?” Breaking things down based on the earth’s rotation is convenient but certainly not agile. The daily stand-up meeting should focus on what’s happening now. The information conveyed should be timely and relevant.

Forget about yesterday and today. Ask “What have you finished since our last meeting?” and “What will you finish before our next meeting?” This phrasing also helps in dealing with personal time off, holidays, etc.

It’s a simple change in mindset that breaks the artificial tension created by our circadian rhythms.

Collaborate! Don’t Hide Behind Priorities.

Picture this — I’ll bet it’s happened to you more than once. Your boss, business stakeholder or customer approaches you and asks you to take on an important assignment. It’s not a major project but it’s not a quick or simple undertaking either.

You already have more work in your queue than you can complete anytime soon. Adding this new assignment to the mix only complicates matters. So you ask the obvious question — “What is the priority?”. Should you drop everything and get right on this? Should it become a background activity that you’ll work on as time allows? Should it be started as soon as something else finishes?

Here’s the problem. Asking the “What is the priority?” question, shifts the responsibility from you to the requester. If the work is not high priority and doesn’t get done, you can always say “Well, you decided the priority.” Technically speaking, that’s true. Practically speaking, you failed!

Our bosses, stakeholders and customers expect us to find ways to get things done. We are the experts — the solution providers. If we can’t get the work done, who can? Pushing the responsibility back on them won’t enhance your reputation or improve your stature in the organization. In the end, people will remember that you couldn’t deliver what they needed. It’s not about priorities, staffing levels or workloads. It’s about getting stuff done.

Here’s what you should do instead.

1. Ask the “Is this a high priority request?” question. If there is a crisis or an urgent need, you want to know and you need to start immediately.
2. If it’s not urgent (and it likely is not), turn the discussion toward what result is acceptable. Rather than thinking in terms of all or nothing, think about a “minimum viable deliverable”. Is there something you can deliver in the short term that will satisfy the core need? You can always add more to the solution later.
3. Consider re-evaluating existing projects and redirecting one or more of them toward a “minimum viable deliverable” to free up time for this new request.

The key point is to collaborate with the requester and find a mutually beneficial solution. When people are reasonable and relationships are good, this approach often works.

Having said that, there will be exceptions. Let’s face it, some people are unreasonable and some relationships are poor. Yet, even if the approach fails, at least you tried. The requester will walk away feeling that you made an effort to help. That effort will likely leave the requester with a better understanding of the issues you face. Maybe next time he’ll be more collaborative.

There’s a lot more to being agile than simply implementing Scrum, Kanban, Lean or XP. Agile is a mindset that begins with collaboration.

Extending Deadlines Doesn’t Solve Problems, It Postpones Them

Have you ever noticed that some companies seem to jump from crisis to crisis? You’d have to work there to see it. It typically goes something like this…

1. There are many top-level initiatives in progress within the company.
2. There’s inadequate staffing so most of the staff ends up assigned to two or more such initiatives.
3. Before long, something goes wrong on one of the initiatives and it attracts top level attention.
4. A company crisis is declared and all hands are ordered to help resolve the issue(s).

Guess what happens next?

1. The immediate crisis is resolved and everyone celebrates.
2. In the meantime, other projects are not getting the attention or staffing they need.
3. And so, another initiative deteriorates into crisis mode and the pattern repeats.

The organization jumps from crisis to crisis — over and over.

Sadly, this is a vicious cycle that’s hard to break. It can actually be addictive. There is a thrill that some managers derive from being a hero by solving the latest crisis. It may become a contest among the management team to see who can solve the most crises and be the biggest hero.

There’s no way to be agile in the middle of crisis after crisis. Ultimately, there are only two ways out of these complex predicaments. A) Reduce the number of top-level initiatives, or B) Add staffing to eliminate the multitasking. That’s it, pick one.

Many managers will be tempted to add a third option — extend the deadline on one or more initiatives and buy time. Bad idea! Pushing out deadlines doesn’t solve problems, it postpones them. They’ll resurface.

Every company faces the occasional crisis needing senior management attention, that’s normal. When the occasional crisis becomes a way of life, there’s a serious problem.

Find out what’s causing one crisis after another. Address the underlying issues. Get back on track. Be agile!

20 Ways to Tell If Your Project Planning Is Taking Too Long

I see too many organizations spending too much time in project planning. Actually, I take that back. They spend too much time thinking they are planning. If you want to be agile, you need to deliver software. Planning helps get you there but it can also get in the way if you over do it.

With that in mind, here are 20 ways to tell if your company is spending too much time planning the project, and not enough time delivering it. (Warning: A few of these may be slightly over the top — at least I hope they are!)

1. The business stakeholders are asking “Is the software done yet?” and you’re still planning.
2. The requested delivery date for the software passes and you’re still planning.
3. You spend more time in planning meetings than you do with your family.
4. Every time you go to a planning meeting, you meet new people.
5. You have to schedule meetings to plan the planning meetings.
6. You call meetings but no one shows up any more.
7. You’ve revised the planning documents at least 5 times.
8. The planning documents are so complex you create a taxonomy to organize them
9. The planning document set is so large you can’t use email to distribute it.
10. Everyone answers “I’ll get back to you.” to information requests yet no one ever does.
11. Writing the code is expected to take 4 weeks yet the planning has dragged on for 6.
12. People assigned to work on the project are being re-assigned.
13. Writing your risk management plan has become a project in itself.
14. The name of the project has changed at least twice.
15. Your email distribution list is so long you need Constant Contact to manage it.
16. Every time you print your planning documents the printer runs out of toner.
17. The same issues, discussions and debates occur over and over again.
18. The development team spends more time playing video games than writing code.
19. The business, tired of waiting, shows you prototype software they are developing on their own.
20. You’ve been planning for so long that the original project goals are no longer valid.

I’m fairly sure you’ve witnessed at least one of these patterns in at least one of your projects. The cure? Stop. Just stop. Write some software. Test it. Deliver it. Plan a little more — caution, I said a little. That’s how agile teams do it.

Have anything to add to the list?

Mindless Activities Will Kill Your Agile Approach

No software development team can be agile without a strong business foundation that allows rapid progress. Implement Scrum, Kanban, XP, Lean or whatever development approach you like. They will all fail unless the business has an agile mindset.

Developers should be paid to think and add value not to perform mindless activities. Let computers perform the mundane. The best run projects draw high value from every team member. In doing so, they create an agile mindset. Here are a few simple tips for establishing an agile foundation.

1. Eliminate redundancy. Information should be entered once and tracked in one place. Tasks should be performed once with traceable results. Maintaining multiple document repositories or capturing the same information in multiple formats is wasteful. Creating a complex organization structure where only designated people can perform certain tasks is anti-agile.
2. Share information. Establish a technical knowledge base. Create a wiki for every project. Use an internal social media platform. Getting any of these elements setup is easy. There are plenty of open-source software tools available. The content doesn’t need to be elegant. It needs to be useful.
3. Abolish approval cycles. Free the management staff to focus on adding value. If information is out in the open and readily available, development processes become self-policing. Establish rules, guidelines and/or standard operating procedures. Then, all you’ll need are spot checks, not approvals.
4. Leverage relationships. Identify your key internal and external stakeholders. Be sure you have a mix of senior and not-so-senior personnel represented. Engage them in the software development effort. Work your butt off to keep them satisfied.
5. Automate and decentralize. No one likes mindless data entry or repetitive tasks. Such activities should be handled by computers. Implement self-help systems for things like training, questions about company benefits, access to company literature, forms, and provider contact information. Free up your staff to deal with real business and technical issues.

Once you eliminate mindless activities, the software development team can focus on being the best it can be. Relieved of the mediocre, your team will be positioned to succeed and empowered to be agile.