- Jack Be Nimble
- Wicked Problems and Gordian Knots
- Jack Be Quick
- Jack and Jacqueline Jump over the Candlestick
- Agile Business Analysis and Iterative Development Cycles
- And Jill Came Tumbling After
- Knowledge Artifacts
- Jack Sprat Could Eat No Fat
- Traditional Business Analysis
- The Requirements Document
- They Have Licked the Platter Clean
This chapter is from the book
This chapter is from the book
This chapter is from the book
Jack and Jacqueline Jump over the Candlestick
We would like to think that all business analysts are agile and nimble, and all projects are agile and nimble. But we know better. We also know that opportunities for being agile are not always there.
So, let us think about your situation and where you fit on the scale shown in Figure 7.3.
)
Figure 7.3 Pure agile business analysis is at one end of the scale. At the other is the more traditional way of doing things. Both are good, but it’s more practical to avoid the extremes. That said, we would like to be somewhere on the left side of this scale.
So how do you move further toward the left end of the scale? By jumping.
Jumping the Silos
Many—probably most—organizations are arranged in silos. By silo, we mean a unit within an organization that does not share information, either deliberately or otherwise, with the rest of the organization. Projects, departments, divisions, or even people sitting at nearby desks don’t share their knowledge. Why? Isn’t everybody on the same team? Aren’t we all working toward the same organizational end goal?
Sort of.
Silos start out as reasonable organizational units to take advantage of human specializations, but later they become entrenched because of interdepartmental or interproject jealousy or rivalry. Or because people are unwilling to give away knowledge that might have taken weeks to acquire. Sometimes people are simply unaware that others might benefit from their knowledge.
A common problem with silos is that teams often feel constrained to deliver a solution contained within their own silo.
A common problem with silos is that teams often feel constrained to deliver a solution contained within their own silo. They feel that they do not have permission to venture beyond their silo; they feel that the inhabitants of another silo will not welcome them or not cooperate with them—that the development team in the other silo will be unresponsive to them or that the chain of command is too difficult to navigate.
This runs contrary to our business problems. Most of the time, a business process is a chain of activities that weaves its way through several silos. Additionally, you would like your customers to be unaware that you have an internal structure. Please don’t inflict your silo structure on them.
Getting the right result might mean having teams from several silos cooperating. Chris Matts, an agile coach, talks of a “scrum of scrums” where the teams come together to coalesce their ideas.
Perhaps the best approach to jumping silos comes from an adaptation of the work practices at Spotify. Using the Spotify terminology, you form a tribe, which is made up of the development teams in each of the silos that have a connection to the complete business process. The tribe is a matrix whereby the people in it have three allegiances. One allegiance is to the project or business process being developed or changed. There might be a project manager or similar person overseeing the complete business process. Another allegiance is to the team members’ manager within the silo (department, division, whatever). The third allegiance is to the team member’s area of competency. For example, a team member who is the main person for testing would get together with the testers from the other teams in the tribe to share knowledge and discuss problems. Similarly, the business analysts collaborate closely to ensure all aspects of the business process are covered. However, the team is still responsible for the part of the process within its silo. This approach is illustrated in Figure 7.4.
)
Figure 7.4 The silos are the vertical columns. These are departments or divisions within the organization; the management structure is shown. The business process crosses these four silos. The teams are formed into a tribe for the purpose of building/modifying the business process. The thin line connects people with the same competency in different teams.
Another way of informally jumping the silos is to use the white space. Look at any organizational chart, and you see a hierarchy with the boxes representing people or roles in neat towers pyramiding down the page. The connecting lines are vertical. There is nothing to stop you from penciling in an informal line between the box that represents you and the person or role whose cooperation you need. We do not know too many managers who actively discourage cooperation when the outcome will be demonstrably beneficial. Our colleagues Tom de Marco and Tim Lister wrote about “The White Space” in their influential book Peopleware—Productive Projects and Teams.
Moreover, we are seeing more and more business analysts who are not attached to a silo and can do more to spread ideas between the silos. The enterprise architect is a valuable ally here. The architect’s role must be involved with the whole of the organization and not just its separate component silos.
Avoiding Sign-Offs
Many organizations require documents to be signed. The signature is intended to indicate that the organization has reached a stage of development that necessitates documents being treated differently or handed off to another team. There are reasons for signing documents, but often quality control is not one of them. Sometimes—unfortunately often—the real objective of sign-off is to become disengaged from the document and the activities it represents.
We have observed that there are usually three stages associated with a formal sign-off:
Prepare the document for signing. This usually means there is a temptation to include more documentation than less. The resultant bulky document is passed along with a “read this and sign it if you agree” request.
Wait for the document to be signed. The waiting time has little to do with the complexity of the document and much to do with the abilities of the signatories and their willingness to commit.
Stage 3 is wondering if the signatories read the document, whether they understood it, and whether having it signed makes any difference to what comes next.
The biggest problem here is that the sign-off comes at the end of the document’s production, not at its beginning. But is it at the beginning of a document’s life—or any other work product—that the most attention and commitment is needed. Whatever you are producing, you need people to engage in the process, not wash their hands of it.
Ask for sign-on, not sign-off.
To be quick and adaptive, you must give your stakeholders work products—documents, maps, stories, models, specifications, prototypes, whatever—that they can both understand and engage with. Ask for a progressive sign-on, not sign-off.
The Blue Zone
The following is extracted from a book of essays we wrote with our Atlantic Systems Guild partners. The book is Adrenaline Junkies and Template Zombies, published by Dorset House, now owned by Pearson. We acknowledge their kind permission to reproduce this essay because it is an appropriate example of jumping over the candlestick.
)
“Orville Wright didn’t have a pilot’s license.”
—Richard Tait, Cranium
Meet Winston. Winston typifies a certain personality that you encounter from time to time on development projects. He’s not quite an anarchist, but he seems to report only to himself. He appears to do pretty much what he sees as best for the project, regardless of his marching orders. And yet, he never really goes too far. He just stretches his authority—and sometimes his manager’s patience—near to the breaking point. Winston operates in the blue zone.
When a manager hands out assignments, among other things he sets boundaries. He sets boundaries to give the recipient enough latitude to achieve the objectives of the assignment, while taking into account the team member’s abilities. The manager also tries to prevent different assignments from overlapping or colliding.
Thoughtful task definition establishes a wide lane within which the assigned team member may operate freely. However, it is almost impossible to specify exactly everything that needs to be done as part of the assignment. We think of project assignments as creating three zones of authorization;The green zone consists of the things that are explicitly a part of the assignment: the core of the work to be done. The red zone includes anything that is explicitly excluded from the scope of the assignment. The blue zone is everything else: activities that are neither required nor prohibited by the assignment. In other words, this lies between the green and red zones.
Our colleague Winston believes that he can do anything that he has not been explicitly told not to do. Not only will he carry out the assignment as stated (his green zone), but he feels he should do anything in the blue zone he thinks needs to be done to achieve the best outcome. His only criterion for acting is that whatever he does must be beneficial to his project. He doesn’t wait for permission; he doesn’t ask for it. He just does whatever he thinks needs to be done.
There is more to Winston. We sometimes see him attempting to persuade the team leader to let him operate in the red zone. Permission to do what he has been told explicitly not to do is the only permission he seeks.
Having a Winston on your team is a real benefit. Although life with him can be hair-raising, he gets things done. And his adventurous nature means he often comes up with better and more innovative solutions than were envisioned by his manager.