The key benefit of the approach is that you do NOT try to understand and prioritise every thing at once against everything else. Instead you break the problem down into very small pieces and move through each one methodically. You then come up with a ranking of the importance of each variable from top to bottom.

And the approach scales well. You can do it on your own or you can get a lot of people to use the process at once to form a consensus about what issues really matter the most. I have used the approach for everything from setting priorities in retrospectives to ranking the capabilities needed in a team to structure more effective training.

An example of where you can use it

For example, lets say you are working with a team of testers who work on projects across the whole organisation. They have been complaining about being unloved and their stakeholders are questioning whether they actually add value to projects.

You do a retrospective with the team to reflect on where they think their could be improvement and you have some meetings with your key stakeholders. As a result you find out that the team could get better at communication, team building, consistent tool use, work quality, knowledge of the systems being tested, working with the developers instead of against them, finding critical defects instead of just cosmetic things, problem solving, collaboration, good manners and a range of other things.

If you decide on one thing to fix then everyone will complain you are not fixing the rest, but if you try to fix everything you will not get anything done. Even worse, if the team don’t see value in what you are fixing then they will not help and you will fail. Even worse again, if your customers don’t see value then they will keep escalating and complaining about everything and you will be too busy apologising (or hiding from them) to focus on fixing things.

So you need to prioritise and here is where you can use stepwise programming.

Applying stepwise programming

The approach is simple. First you create a matrix with the items you want to prioritise listed in both the left hand column and the top row:

Next you start on the first row and compare the heading you put in the left-hand column with the heading you have put in the top row.

• If the variable in the left hand column is higher priority to the the one in the top row, then enter a 1. Otherwise enter  -.

For example I think it is important for the team to get better at both root cause analysis and collaboration. But if I had to choose between them, then I would choose root cause analysis. So I would enter a 1 in the appropriate field. I then continue through the first row doing the same thing:

Similarly, if instead of doing the exercise on my own I had my whole team of 6 people do the exercise I would get each person to complete the row separately and then update the table with the total votes that people gave to Root cause analysis compared to everything else:

So I could say that the team think getter better at root cause analysis is more important than getting better at collaboration and (unlike what I think) the team as a group believe that getting better at root cause analysis is even more important than using automation to improve testing.

But the real benefit comes when you have completed the whole table:

So you can see from the table that the team (as a group) believe the biggest benefit would come from getting better at root cause analysis. And if we could pick a top three to focus on then we would pick Root cause analysis, Collaboration and Use of automation.

The numbers may not add up in this table because I just made them up quickly. But even in the real world some people seem to vote that (say) root cause analysis is more important than collaboration the first time you compare them and the vote the opposite way the second time. To counter this, some teams only allow comparison once and then simply put the number (6 – 5) in the field that has collaboration as the left-hand heading and root-cause analysis as the top. But I don’t do this, because I think even that flip-flopping can help you get a better understanding of where the team feels the value is.

In the real world, I often use this technique when there are between 10 and 20 variables to compare. I find it a really good way to prioritise when I am faced with both intangible stuff (values and preferences) and great complexity (too many variables for my little brain).

Of course it does not tell you how to fix the problems, only which ones the group really think you should focus on first.

Interestingly it turns out the real world is harder and more ambiguous than the projects in my training slides

Having said that though, the fundamentals don’t seem to change. We have stopped a project and are about to restart. It is really urgent and we have inherited a project whose budget (in time and money) has already been spent. So we really need to get going.

But are we better off starting or are we better off getting our act together before we start so we are not “mistaking activity for progress” by rushing off in the wrong direction?

What I say in my training courses is to get the team together and brainstorm everything that needs to be in place before we start.  Then prioritise these ideas using MOSCOW and spend your first iteration (or sprint) nailing those stories.  Then if you have not done all the “must haves” then don’t start and if you have not done all the should haves then you know your next retrospective will include “should not have started before …”.  But with your should haves you can turn them into risks or tasks to do in the next iteration or two by dropping some stories to make room for them.

Great, I can’t fault the logic, but now I am in the real world and the development team is already off and running on some of the things they know need doing for our first urgent release, while some of the team are yet to arrive on site.

So here are the must-have’s I am applying.  Let’s see what happens.

1. Do we know where we are going?
• Do we have a Mandate to do the project? Ie
• Do we know the problem we are solving (yes). 
• Do we have funding allocated and not just “soon to be sorted”. (Yes)
• Do we have a complete backlog that the whole team understands (no).  Eek … do we know what to do for the first release? (Yes – we need to be ready to integrate some functionality for the other key project by the end of next month.
• Do we know our scope and priorities? (Yes-ish, er that is to say roughly yes) [which is probably the most dangerous answer of all].  (But we do know the scope for t he release in one month and we know our first priority is to hit that deadline subject to our other first priority of sufficient quality is mandatory).
• Have we defined success? Do we know what “good” and “fixed quality” actually mean? When is a story done? What non-functional requirements need to be meet to release? (Er No we are not really clear yet)
2. Do we know how to get there?
• Do we know what practices we are using? (Yes – we are stealing them from the project we need to integrate into).
• Really? Do we have planning and showcase meetings booked (yes). Do we have retrospectives and standups? (Yes)
• Do we know what technologies we are using? (Yes, except for some of the bits).
• Do we know who is doing what on our project? (We have a sponsor, a product owner, a scrum master, a BA, some developers and a project manager). Again – Do we know who is doing what? (They should do, they know their job titles, except the Scrum Master, I am not sure if we told him that he is on the project to the bitter [or joyful] end). In other words – We need to be clear on what they actually do. Cool – do we have an architect and a tester? (Long pause … oops)
• Do we have a test strategy that is understood by the whole team? (No).
• Do we have a publicly available risk register? (No but the PM is listing and discussing the key risks)
• Do we have a high level architecture that is understood by the whole team (coding standards if we want them, standard tools, guiding principles and of course a big picture on a wall or whiteboard of the context diagram and dataflow diagram (or domain model or strawman or something). (Yes-ish)
• Do we know the biggest constraint that is likely to inhibit our success? (Yes and no)
• Do we know the few things that really need to be done well and the other things that need to be done well enough to succeed? (sort of) What has to work for us to succeed and what has to be done really well? What will be forgiven and what will be remembered after the project is done? (er … yes)
• Do we have a road map of what is being released in what order, say epics per release? We have lots of stories and epics in Sharepoint, Jira and Version One. But we do know what needs to be done for the end of the month and we are consolidating to one backlog in the coming days)
3. Are we set up to succeed?
• Do we have the right people? (yes)
• Have we moved to one location (No – same planet but different countries)
• Have we cleared the decks of all other distractions (no – some of the core team are on other initiatives)
• Do we have real buy-in and trust from both the team and the business stakeholders (yes)
• Have we all worked together before (no)

The trainer in me is screaming stop. The enthusiastic optimist in me is calmly saying we have been here before and the crew is a good one so we will pull it off.

But the project manager in me is comparing risks against each other to pick the least worst (or should I say best) options. (I am not the PM on this project but I will sink or swim with him so my inner PM is talking loudly in my head).

So here is my current cunning plan:

• Get the test strategy in place before anything else.  Then make sure we have a technical scope and high level architecture diagram that we can show both the related project and the business customer.
• Define Done, Quality and the “what do you really do” part of the key roles
• Break the project into “imminent release” and “rest of project” and get on with some of the imminent release while sorting the rest out.
• Smile and look confident while copping a schalaking from the sponsor for not being fully ready.  Calmly repeat “its better to be unhappy now than at the end of the month; It’s better for the team to commit than to force them forward before they are ready; We know the biggest constraints and we are focussed on managing them first; stop hitting me, its not really appropriate).
• Expect to only deliver one quarter of my potential velocity in sprint one because I am really doing sprint two late.  Maybe I should delay to sort things out but that always seems to rub me the wrong way.What

What would you tell me to do?

But there is an explanation – My most recent project has been consuming more of my attention than expected.

Project New Baby (Or since we normally use acronyms in IT – “PNB”) involved the development and delivery of the next generation of peopleware for the King household (ie a baby).

Since the project was run by my wife, who is an exceptional project manager, the project delivered earlier than promised, which sounds good.

But there is a thing called project Karma that came into play on the delivery date. I have delivered a lot of IT projects in my time and have sometimes been guilty of saying “We can do that in warranty support” when I encounter things that could delay delivery of my project. I have even managed to deliver a project early by shifting some of the work into the forthcoming production releases.

The down side of deferring things to warranty support meant that the issues left behind were dealt with by a shocked looking and under-prepared production support team.

Beyond the short term impact though, the theory of project karma states that the luck you have on your future projects will be impacted by the good and not so good things you have inflicted on others in your previous projects.

So it should come as no surprise that although my wife delivered PNB earlier than expected, the warranty support team of two (my wife and I) found themselves under-resourced and poorly trained to support the new baby in production.

Consequently, I have been in a state of perpetual chaos for the last month or so, dragged away from other endeavours to support the new release.

On the plus side though, PNB has exceeded stakeholder expectations in customer satisfaction and other key indicators.

To become a Certified Strum Muckster you need to meet the strict sounding entry criteria for the International Strum Alliance and then abide by a number of rules that have been deemed by the International Strum Alliance  (currently me) to be the one true and correct way to create and deliver training courses.

Strum Alliance Membership

• James King

His mother also said that she would join if nobody else did so he wouldn’t feel bad … Though she hasn’t actually turned up yet.

Conditions that must be met to become a CSA

Potential Strum Mucksters  need to follow the correct pathway toward Strum Muckstery. No exceptions are allowed and unfortunately no credit can be given for existing qualifications or experience. This is to ensure the maintenance of the highest standards demanded of Strum practitioners.

1. The potential Strum Muckster must deem themself to be certified. Unfortunately the current volume of applicants and the inherent laziness of the existing membership of the International Strum Alliance means that nobody else has time to certify you. So certification will be strictly performed on a do-it-yourself basis.
2. If the newly qualified CSA wants a certificate he or she will need to work out how to print one.
3. The Certified Strum Muckster must use the title Certified Strum Muckster or CSA (Certified Strum Acronym) in at least one conversation, email or a comment on this blog.
4. The CSA must agree to absolutely not pay a membership fee of $22.50 per quarter to James King for the privilege of ongoing membership. Those who do decide to pay the membership fee will need to cease using the CSA qualification and instead adopt the title of RSBC (really should be certified). They will also need to look in a dictionary to find an alternative meaning for “certified”.

The rules of Strum

As with all true and correct approaches to building training, there are a number of rules that must be adhered to, unless you decide to break them.

The approach to learning the Strum method is similar to the approach used in learning many project methodologies and indeed the secret martial art techniques of the Yue Bet monastery:

1. Learn the rules
2. Follow the rules
3. Break the rules

In the Yue Bet approach to martial arts, students are expected to learn a technique, practice the technique until they master it and only then adapt the way they apply the technique to create their own style.

The same approach applies to learning many methodologies.

Practitioners must first learn the rules of the methodology, then they must follow the rules and learn what happens when they do so in the real world, after which they usually break the rules because the rules turned out to be quite silly and unrealistic when attempted without modification in a real project.

The same applies to learning Strum with one modification:

The 3 steps listed above must be closely adhered to. However, the CSA is free to apply the steps in any order.

Rule 1

The best way to train and learn is through face to face conversation, preferably through interaction in solving case studies as a group.

Having said that though, books are pretty interesting too and some of the new technologies like youtube and e-learning are pretty amazing. So use those things instead if you want to.

Rule 2

The correct class size is 5-9 students and 1-2 facilitators (CSAs).

But you can’t always find 5 people and sometimes you want to have more in the class so do that if it makes more sense.

Rule 3

The difference between the wise man and the fool is that the wise man can learn something  from anyone, even a fool.  But the fool will not learn from anyone, not even a wise man.

So if you have mastered your material to the point where you won’t find yourself learning from your students, nor being corrected by them in front of everyone else … then you can be sure that even the wisest of your students will still have something to learn from you.

Rule 4

Strum Mucksters do not seek to provide students with the correct answer but with the correct question.

That way the student has to do all the thinking and the strum muckster can drink cappuccinos.

Rule 5

Learning is optional but catering is compulsory.

In the end each student will only learn what he or she wants to learn but the CSA must cater to each student’s individual learning style AND provide muffins.

Rule 6

The Certified Strum Muckster must possess emotional intelligence and develop the appropriate level of soft skills.

If nobody got upset or uncomfortable during the course then you were probably too soft.

And if there was blood left on the carpet at the end of the course (particularly your own) then you probably should have been more tactful, or you might have pushed the learning too hard instead of remembering rule 5.

Rule 7

PowerPoint slides don’t bore people, trainers bore people with PowerPoint slides.

So feel free to show as many slides as you want and include as many bullet points on each slide as you feel you should add … even if someone said you should only have one idea per slide, no more than 3 short lines on each slide and no more than 10 slides for a one hour presentation.

Similarly you can feel free to replace all the boring PowerPoint slides with cool photos that you like and streaming videos all over the place.

After all a picture is worth 1,000 words so a presentation with 50 unrelated pictures is like a presentation with 50,000 unrelated words.

Rule 8

When the student is ready then the teacher will appear.

But when the teacher is ready then the student will probably be stuck in the middle of a major project and he or she won’t be able to come to the course.

That sucks a bit but its a rule so what can you do?

(Note: “That sucks” is a technical term meaning “that is quite unfortunate”).

Alleged Rule 9

Your aphorisms are clever but probably not useful to the student.

You will always add just one more concept to the course because it is worth knowing  … but when you run the course you will realise that you should probably have stopped and let the other material sink in.

So there are only 8 rules and you should not be reading this alleged rule at all.  Go back to rule 1 or get out there and break the other rules.

Conclusion

The International Strum Alliance is now officially recognised among its membership as the single credible source for international trainer certification against the rigorous sounding standards of the alliance’s primary certification.

Please consider joining us if you feel you have the ability to rise to the challenge and the time to dedicate to the certification process.

I guess the answer is yes, but …..

I believe that you can certify anything if you can define and measure it.

So you can certify an accountant if you can define and measure the things an accountant should be able to do. I would not go to a tax accountant unless they were part of a professional body because I respect the professional bodies and trust that their “certified members” abide by a set of skills, practices and ethics that embody what I think their profession is.

Along the same lines I think you can certify a person as a project manager (or business analyst, tester or developer) if you can define and measure what they do.

So I like the idea that someone is certified in DSDM/Atern (Prince2 branded agile) because it is a set of processes and practices. This means that certified in Atern means someone knows what the practices are if I want to use them to run my project. But it does not mean they are a good agile project manager.

But I don’t hire people because they know what Atern is. I hire lucky project managers and innovative developers. So it would be awesome if I could Google (for example) CLPM – certified lucky project manager and find one, but I am not confident that I could.

So my concern with certifying someone as agile is that I am not sure how to define and measure what we collectively mean by agile.

I would be happy to rate someone “certified by James King as being good at running agile projects” because then people can use my credibility (or lack of credibility) to make a decision about whether to hire the project manager.

But in the absence of a single recognised body of agile professionals who have defined the finite list of practices and ethics that their members abide by, then I am not sure what “certified in agile” really means.

So I am happy that someone is certified by Prince2, Scrum or PMBOK as knowing what they think agile means and meeting the entry criteria for their respective groups.

But I don’t yet see how that means they will be able to meet my definition of agile leaders (to adapt their approach to the context of the situation or encourage effective interaction and creativity in a team). So I am not yet convinced that there is such a thing as an effective certification for agile, for lucky or for innovative.

We spoke about agile maturity models, agile certification, real agile versus pretend agile and even whether there was a right way to do agile. We did not come to any agreement about whether certification and maturity models were good or bad but we did agree there was no one formula for success in agile.

This seemed logical at first but then I thought there really should be one formula we can apply. That way we can simply measure people on whether they are using it and correct their approach for them.

So after minutes of detailed research and experimentation I came up with the following formula.

In case it needs a little explanation – Success in agile is a function of:

• The sum of the ability(Wi) and care factor (accountability or ACi) of each person in the team divided by their individual cowboy like tendencies (CBi) where n = the number of people in the team;
• Multiplied by the ability of the team to self organise (A-so) and the effectiveness of the governance of the organisation (G-c)
• Where the ability to self organise is equal to the delegated authority (DA) of the team and the clarity of the boundaries the team can speculate and innovate within (CB).
• DA is equal to 1 minus the misalignment of accountability (what you are blamed/rewarded for) and authority (what you can change or make happen/fail). Note that this is regardless of whether you have accountability for what you don’t have the authority to make happen or you have the authority to do things that you are not accountable for (ie someone else gets blamed for).
• All divided by the factors that make it harder to be agile – the number of people in the team ( n) plus the real constraints holding the team back (RC) plus the organisational antibodies that attack new ideas with false constraints and other weapons (AB);
• All multiplied by the team learning factor (LF) which is equal to the sum of the team’s willingness to learn (Wl) and their ability to learn (Al) less the ”Safe to fail fudge factor” (Sf). Sf in turn means the extent to which the organisation says it is safe to fail in general but not this particular time.

Applying this simple formula should therefore lead to successful agile.

Taking it a step further, we can use the formula to produce the following pattern that we can imbed in our code to automate the process in a sub-routine. This is written in King 2.0 but can be translated into Java or Ruby on Rails:

Turns out to be easier than many people think – certainly easier than developing standardised maturity models and robust certification of good agile.

Of course there will be a delay before we get the code written and tested, so in the meantime I guess we can use the following workaround ….. the team should try to do the best they can, measure what happens and try to improve. But since others have also tried before and measured what happens the team should try to learn what others did and add that to their kitbag so they can try to apply the same approaches themselves.

There is no sound so they may not make too much sense without any context, but here they are anyway:

http://prezi.com/vllsdawtxfxv/but-where-do-the-stories-come-from/

They are created in a free software package called Prezi.com that allows you to zoom in and out of material so you can present a mindmap rather than a set of slides.

I am sure with practice and creativity you can create far better presentations, but even as a first try I found it really easy to use.

(If you have not caught up with Penny and her adventures yet then you can read on from here or you can start back at the beginning. Penny had recently become a manager, even though nobody had asked her is she wanted to be one. She was now off to her first management meeting and wasn’t even sure what she was supposed to talk about there).

Penny came into the meeting room and found that most of the seats were already taken. But Sue had saved her a seat so Penny went to sit with her.

All the managers gave updates and they all said things were going really well in their teams.

Eventually Sue gave her update and she introduced Penny. Sue explained that they had appointed Penny to spearhead the new agile support team.

‘”And how is the new team going?” Asked Steve Hammer, who was a senior executive.

“Extremely well,” Sue responded, which surprised Penny a little because she hadn’t had time to talk to Sue yet to actually let her know how it was going.

“How do you think things are going with the new team Penny?” Asked Steve.

“I’m not sure,” said Penny, “We are starting some new agile practices but we don’t really know what we are doing yet”.”

“Yes they do,” corrected Sue, “Things are going really well, we are already noticing a feeling of increased agility across the wider team, and people are really impressed with the early wins the new team is delivering.”

“Such as?” Asked Steve.

Sue looked at Penny hopefully.

“Well,” said Penny,” we are having standing around meetings every day and we have started to use pear shaped programming a bit.”

Most people listened with interest, but Sue was looking decidedly nervous.

“Are the new practices helping?” Asked Steve.

“Helping with what?” Asked Penny.

“Exactly,” said Steve.

Penny looked at him, not sure if he had really answered her question. Then after a moment Steve seemed happy with her response.

“Good,” he said,”So Penny is starting to understand the issues.”

Sue looked relieved and Steve looked like he was going to move onto the next update. But then Penny interrupted him and Sue nearly jumped out of her chair.

“What issues?” asked Penny.

“Exactly,” said Steve, “Exactly.”

“What does that mean?” Asked Penny

“Exactly,” said Steve and everybody nodded along with him.

“But that’s not really an answer,” said Penny.

“No,” said Steve, “I guess its not, at least not a useful one.”

The meeting continued while Penny sat there wondering if she had missed something.

Eventually everyone finished saying how well things were going and it looked like the meeting was about to end.

“Oh, one more thing,” said Steve, “I am quite interested in how your team is going Penny, do mind if I come to meet the team?”

“I think that might help,” said Penny, “We have a standing around meeting tomorrow and a practice meeting on Thursday.”

“Great,” said Steve, “Are there any key messages you want me to reiterate while I am there?”

“I guess you could tell the team what you want us to do.” said Penny

“The problem is though, that if a senior manager tells people what they want, then people never seem to listen. So its often better to not tell them.”

“But what’s the point of being a senior manager if you don’t tell people what to do?” Asked Penny.

Steve was about to answer when Penny realised he what he was going to say “And Don’t say Exactly” she quickly added.

“OK,” said Steve, “I will give you this one answer, but if I tell you too much then you won’t understand. So I will try to be as vague as I can be.”

“The job of senior management is to help regulate the distress everyone is feeling. If you can do that then you can pretty much let everything else take care of itself,” said Steve.

“I am sure you do more than just help people calm down if they are getting distressed, don’t you?” said Penny.

“Exactly,” said Steve with a smile, “You also have to help them become more distressed if they are too calm”.

“How does distressing people help them?” Asked Penny.

“Exactly,” Said Steve.

Penny was starting to think that inviting Steve to their standing around meeting might not be a very good idea if all he was going to do is go around distressing people.

“On second thought,” said Penny. “My team are actually feeling exactly distressed enough at the moment, so you can probably skip our meeting if you like.”

“That’s good work indeed if they are already just the right amount of distressed, but are they distressed enough about the right things or are they too stressed about the wrong thing?” Steve asked

“Exactly,” Said Penny, hoping that was the right answer.

“It sounds like they are a bit too distressed then. I better drop by after all,” Steve answered.

Penny looked distressed.

“I think I might be causing more distress than you need right now,” Steve said, “Most people don’t really understand the point of senior management but since you a pushing back on me, maybe I can help a little”.

“Only if you help me become less distressed rather than more,” Said Penny.

“OK, if you are sure,” Said Steve, and seeing Penny nod he continued:

“In the old days senior managers used to tell people what to do and people would do what they were told and that worked really well for a time. But it worked so well that companies got bigger and bigger.

But as they got bigger and bigger the senior managers started to know less and less about what people actually did in their jobs. So when people did what they were told, they were often doing the wrong things even though they knew a better approach themselves.

So eventually senior managers started to get out of the way and just let people do what they thought was the right thing to do. They made sure they gave them the tools they needed and then let them work out how best to do their jobs.

But then companies got into trouble because all the people were doing different things that made sense to themselves, but not to other people. And then they would get into arguments.

So managers started trying to calm everybody down so they could work together better. And that worked for a while but then some companies got into a lot of trouble because they were staying calm by ignoring big problems that they should have worried about a lot more.

So some managers would come and get upset when things went wrong and tell people not to make the same mistakes again. But people would become so worried that they would make new mistakes while trying not to make the old ones again. So everybody was getting too distressed.

Finally senior managers realised that it was no good getting people distressed or getting them to always be relaxed. Instead they had to make sure that people were only getting distressed about the right things, while not wasting time being distressed about everything else.

But if you actually tell them what to be distressed about, then they will do what you tell them to do. And since they know more about their job than you do then they will probably be focussing on all the wrong things. And even if they focus on the right things then it means that there are other things that they are not focusing on, which will soon become the things they get distressed about, but too late so it will become too distressing.

So instead of staying focused on something that was distressing the team, senior managers have to learn to be easilly distracted and to have a short attention span. That way they can always help to distress people about new things that they were not previously focusing on.

In essence you have to learn to help people stay distressed enough about the right things without telling them what to be distressed. It works much better that other things we have tried.

“But how do people know what to be distressed about if you don’t tell them?” asked Penny.

“Exactly,” said Steve, “that’s the question most new managers forget to ask, and that’s what I would be the most distressed about at the moment if I was you”.

“Is that why you sent an agile consultant to help us? So she can tell us the answer?” Asked Penny

“Zara is definately there to help and the good thing is that she thinks she knows the answer, but she is wrong. So she will keep being distressed about not being agile enough, which means you don’t have to be distressed about that, since its not really the answer at all,” replied Steve.

“But if she doesn’t know the answer then how can she help.  It sounds like she will just make us more distressed.” asked Penny

“Its like in the old story of ‘the consultant and the magic nails’ really,. As a consultant she doesn’t know the answer any better than you do, but she has a magic nail, which makes the team focus on solving the right problems. And then you can give the team the answer they need to solve the problems,” said Steve.

“But I don’t know the answer,” said Penny, “Can’t you or Sue just tell me?”

“But if we tell you then you won’t understand, thats the whole problem” said Steve, “ I can help by talking to the team to help you work it out if you like”.

Penny wasn’t sure whether she liked that idea or not. But there was nothing else for it so she agreed to let Steve come to the meeting after all.

“But if you start distressing the team too much then I will have to ask you to stop,” said Penny.

“Exactly – you really do understand management Penny,” said Steve, “And feel free to ask me to distress them more if you think I am making them too relaxed”.

The panellists all explained that BA’s are really important members of the team. This was comforting for the audience but didn’t really address the question.

Then I ran a BA course and one of the participants asked the same question – What is the role of a BA on an agile project?

So one of the other participants summed up what nobody at the conference had wanted to say. He was a developer on an agile project that had no BAs at all and things went really well.

The developers spoke to the people from the business and they found that they could all speak the same language. In other words they felt they were better off talking directly to each other and uncovering misunderstandings and assumptions directly rather than having an ambassador (or translator) running between them.

Our hardy participant then went on to say that he thought the addition of a BA on that project would have been a distraction rather than a help.

This was disturbing news for the the other participants in the room. We discussed ways that a BA could have added value, but we found that we were trying to invent a role for the BA rather than meeting a real need.

Then our hardy participant said that he was also on a larger project where the BA’s added a lot of value.

Apparently not all the stakeholders on the large project could be fairly represented. So the BA’s went outside the project team to explain the project to those stakeholders not close to the action and to gather their needs.

So they worked very much in the same way they would do on a waterfall project, except that they needed to work with stakeholders continuously as the project evolved rather than in small bursts at the beginning and the end..

In addition the BA’s brought skills to the team around understanding processes, looking at the impact across teams of the stories and features the team were working on and asking both dumb sounding and uncomfortable questions to help the team focus on what was really important.

In other words the role of the BA on the larger project had not changed significantly. The requirements document was gone but the interviews, workshops and even some informal modelling tools were still there.

We then discussed my experience and the experience of a couple of the people who had been on a lot of agile projects.

After the discussion I promised to capture that information in my blog. So, some weeks later, this is a summary of our own unverified views.

As you will see there is not one answer to the question but several, partly contradictory ones:

Increased focus on facilitation skills

Some business analysis are excellent facilitators and since there are many workshops in agile projects, the role of facilitator has almost become the primary role of some business analysts.

Some have ended up being the Iteration Manager (or Scrum Master) because this role can be a facilitation one. Others stay in the role of business analyst but take on the running of meetings, the facilitation of requirements workshops and so forth.

This is good news for BA’s who love to facilitate but not such a good fit for strong technical analysts and BA’s who are strong subject matter experts rather than facilitators.

Merging of business and system analyst roles

I hadn’t noticed this one because i have not been working with teams that have specialist “Business – BA’s” and specialist “IT BA’s” but I am told that in some agile teams the specialist BA’s are becoming generalists, focusing on generic skills rather than their old domain.

Return of the system analyst

In complete contradiction to the idea that BA’s are becoming more generalist than specialist, some IT business analysts are apparently returning to the old fashioned role of being the one who understands the impact across systems, the impact across processes and also the requirements of the production support teams.

This appears to be because agile teams are basing more decisions on the views of people in meetings rather than the guidance provided by a technical document. This had therefore led to an increased need for someone who knows which decisions the team can make safely and which ones should involve other IT people.  Thus the system analyst BA performs part “canary in the coal mine” by becoming worried about impacts before others do and part subject matter expert in IT.

Related to this some developers are apparently migrating into a system analyst type role as they get asked to perform spikes (analysis) beyond the application specific code the team is working on. Apparently this is in addition to the role of a solution architect (who designs the technical solution) and the technical guru who leads the developers in understanding their turf.

Usability and non-functional BA / designer

Some web related teams are starting to focus on end user requirements rather than business requirements. Sometimes this involves interviewing users but it often goes far beyond this into interaction design, prototyping and modelling and fully fledged research.

Personally I don’t see this as the same role as the traditional analyst, but I do see it as a fresh new career if I was an eager young BA.

I also have my own theory that we are able to measure more and more on the web and it is getting easier and easier to measure things effectively. But at the same time very few teams take advantage of this or know how to determine what to measure. So I personally see and increasing role that would suit many technically minded BA’s, where the BA becomes the person finding out what decisions should be made on anything that is measured and then works with the technical and business teams to build the right reporting into the system.

Outside the web development teams, according to scandalous rumours, some agile teams are forgetting about non-functional requirements. This appears to be because they see stories as the only requirements on the project and only capture functional requirements through the stories. So some business analysts are getting involved in measuring or gathering information related to accessibility, portability and anything else that is spelt x-ility.  This sounds like a good thing, although I wonder if this role is best suited to BA’s with a background in the right “ilities” or with the ability to know where their own approach should give way to expert input.

Becoming the boss (product owner)

Some teams use the traditional Scrum role of “Product Owner” and this is similar to the BA role, except that the product owner makes decisions on behalf of the business. And in some teams the business analyst is falling into this role almost by accident. The danger is that the business analyst might go “mad with power” and forget to get stakeholder input but there is a good fit here for the BA who possesses commercial acumen and a keen sense of what matters to the business owners.

In some teams this role is called producer, where it also includes owning the vision for the site being developed beyond the one project.

Tester business analysts

Some teams are starting to merge the role of tester and business analyst to almost be the “consultant for all non-techo stuff” for the project. This works well in my opinion where the BA is a strong tester or even better the tester is a decent analyst. But the business analyst needs to move into testing properly and not just do “BA testing”.

Business architects and enterprise analysts

Quite a few agile projects have mistaken activity for progress in that they have done lots of coding and built cool new systems but have not provided user support documentation, process changes or business integration.  As a result these projects have delivered what they think is the project very quickly but have failed to deliver any value.

So there is an increasing recognition that agile projects have to understand and interact with the business processes, business structure, business capability and so forth. So some teams are promoting the business analyst to become a business solution architect.  This means that the BA is now responsible for process change, value measurement and other related areas.

This suits the strongly “business-technical” BA’s but is a stretch for the generalist BA’s the subject matter experts who have become BA’s by accident and the IT focussed BAs.

Technical writers and trainers

Some projects are using the business analyst to run workshops for the business or for end-users and this role is sometimes being extended to take on writing technical documents, creating old fashioned training courses and even creating videos, e-learning and similar artefacts.

This is a role well suited to some business analysts who are willing to learn new skills and push the boundaries of their old roles.

Librarians

Lean manufacturing and agile development are both supposed to be about knowledge management and exploitation. But some agile teams have made the mistake of thinking the only knowledge that matters is the knowledge needed by developers to right code.

There is a gradual recognition however that agile projects are really well placed to create user support tools, production support handover materials, improved knowledge management for business users and so forth.

But creating this knowledge is a demanding role that needs a continuing focus throughout the life of the project. It also requires the creation of knowledge in some kind of format that will live on beyond the life of the project.  For some teams and some business analyst I personally think this creates some real opportunities to define and carve out a new role as a librarian (though people seem to think we should find a different title).

Conclusion

The frequently ambiguous nature of the BA role means that the role is under threat in many agile teams. Business analysts who struggle to explain the value of the work they do are sometimes struggling with their role.

And even some very experienced analysts are finding trouble integrating the key components of their old role into the new approaches being adopted by the team.

At the same time other business analysts on agile projects (particularly in larger organisations) are finding their role is not very different from what it has always been.

And other BA’s are starting to find potentially scary but exciting opportunities if they can carve out a modified role and push themselves to develop new skills in areas related to, but not historically included in, the traditional business analyst role.

Penny decided to start their second day with a team meeting and she bought everyone a coffee as a welcome to the team kind of gesture. Penny wasn’t absolutely sure, but she thought managers were allowed to charge coffee to the company when they had important meetings.

“How are things going?” Penny asked nobody in particular.

“I think we met our targets,” said Aesop the ex mainframe developer, “we ran out of work late in the day but Peter phoned the call centre and logged some new issues and that kept us busy until home time.”

Penny wasn’t sure that they were meant to call in their own problems to work on, but she thought she would stay quiet for the moment.

“Well,” began Zara Zealot the agile coach, “Maybe I can explain some of the agile practices so we can start being more agile”

Everyone agreed this was a good idea, so Zara continued, “The first thing most agile teams adopt is the daily stand up meeting.”

“Like we are doing now?” asked Penny

“No not really – in a stand up you say what you did yesterday and what you are doing today”

“Like we just did?” asked Alice

“No – everyone has to say what they did, not just Aesop. And you can only have 15 minutes”

“But we all did the same thing” said Alice

This was turning out to be a little harder that Zara had expected.

“Don’t worry about stand-ups for now,” she decided, “we are not really agile yet so we can start them tomorrow.”

“But we are already having the standing around meeting so we may as well finish it” said Aesop

“Its a stand up meeting” responded Zara

“That’s right,” said Aesop “These standing around meetings are a lot like the ones we had in my old mainframe team. We used to stood around having coffee to start each day and we didn’t even know how agile we were.  I like this agile stuff.”

Zara decided to stop talking about stand ups before things got too confusing.

“OK,” said Penny, “that sounds like a good idea – lets start each day with a quick standing around meeting”

The team all agreed this was a good idea. Except Zara who sighed and looked like she was going to say something, but then remained silent.

“What else do we have to do?” Asked Alice

“Well,” said Zara, “We could talk about some of the practices like TDD and pair programming to see if we can make use of them”

“We used to do those in Mainframe” said Aesop

“I’m not sure that you would have, Aesop. They are pretty new,” said Zara, “Are you sure you know what they are?”

“Of course”, said Aesop, “Pear shaped programming is what you do in a crisis”

“You mean pair programming” said Zara

“Yep, like I said, when there is a crisis we would say things have gone pear shaped. So we would get two developers to sit down together to urgently fix things before everything went even more pear shaped.” said Aesop

“NO NO – that’s not pair programming at all,” Exclaimed Zara, “in pair programming two developers get together and work on the code at the same time – but its not about making things pear shaped, if anything its about stopping the code from going pear shaped”

“That’s what I said isn’t it,” said Aesop who was looking a little confused.

Everyone nodded. It did sound like Aesop had been doing pear shaped programming properly.

“The difference is that in pair programming you ALWAYS sit together and work on the same code, not just in a crisis,” Zara explained.

“Why would you do that? You would only get half as much work done.” Said Penny. She didn’t mean to be rude but it didn’t make much sense to her.

“I think I know what she means,” said Peter, “Its the ancient Greek principle of thesis, anti-thesis and synthesis.”

“The Greeks didn’t do programming, so how could they have been pear shaped programming?” asked Penny.

“We don’t do any programming either,” said Peter, “we are a support team, not a development team.”

“That’s a point,” said Penny, how do we do pear shaped programming if we don’t do any programming?”

“It’s not pear shaped programming, its pair programming,” said Zara, sounding a little annoyed.

But Peter continued his explanation anyway.

“The ancient Greeks were quite bright and they spent a lot of time looking at how to solve problems,” explained Peter.

“They noticed that if a problem was simple enough then anyone would come up with the same solution, and that would be that.

But with a really complicated problem, when two people looked at it, they would often come up with two theories as to what the best solution was. So they would call the first solution a thesis and the second solution an anti-thesis.”

“Why didn’t they just say they had different opinions?” asked Penny

“Its to do with being a philosopher,” replied Alice, “But I like this story so lets see how it ends”

“Thanks,” said Peter, “being philosophers they argued a lot about who was right, much the way developers argue these days. And just like developers they often tried to win the argument rather than solve the original problem.

In fact a whole group of philosophers called Sophists came along to teach people how to win arguments without needing to understand the actual problem”

“Now that sounds like fun,” said Aesop, “Maybe we should do Sophist Programming.”

“I am not sure Peter has fully understood the who the Sophists were,” commented Alice

“How do grads know so much about philosophy?” asked Penny

“I studied a double major in testing and philosophy” said Alice, “So I spent a lot of time arguing about how the Greeks used to argue”

“I didn’t even know you could do a whole degree in testing,” said Peter

“You can’t anymore, they had to cancel the degree,” said Alice

“Shouldn’t we be talking about pair programming?” Hinted Zara, “rather than about how Alice used to argue about how Greek philosophers argue? This is not quite how stand ups are meant to be run.”

But people were more interested in why you couldn’t do a testing degree anymore. After all there were more jobs around for testers than philosophers.

Eventually Zara got them back on track. She was about to explain pair programming properly when Peter continued his story.

“Anyway,” said Peter, “Some of the Greeks realised that often neither the first solution nor the second solution were really the right one.

Both people would think they were right, but it was only when they understood each others views that they would discover they were both wrong. This realisation would lead them to the real solution, which they called the ‘synthesis’ of their different ideas.

From then on, if they had a simple problem then they could get one person to solve it on their own.

But for really important or complicated problems they would get two people to think about the problem and then bring their thinking together to find the best solution.

“I think I see what you mean,” said Penny, “So in our case I would say that the call centre can handle simple problems on the phone. But if they pass a problem onto us then it is probably either really hard or really important. So instead of having one person look at it we should always get two people.”

“That’s it,” said Peter.

“So we could have the first person think of a solution and present it to someone else who will try to find holes in their idea and then present their own view back. Then the two people can sit down and have an argument,” said Aesop.

“That sounds more like Sophist programming though,” said Penny, “because people are arguing about whether their solution is right rather than trying to understand the problem. With pear shaped programming, I think both people should sit down at the beginning and try to agree on what the problem is and then on what to do about it. So they should really have to keep working together right from the start.”

“But what if it turns out to be a simple problem after all, then we might not need to have two people work on it,” said Aesop.

“Good point,” said Penny, “so we will always start with pear shaped programing but then if the two people agree it is a simple problem then one of them can keep working on it while the other one goes to do something else. So lets adopt pear shaped programming like that. What do you think Zara?”

But Zara had wandered away a little and was quietly mumbling to herself “I must be patient, every team is on its own journey, its not my fault, every team is on its own journey”.

“And don’t forget we are also doing standing arounds every day now,” said Alice.

“What,” said Zara, re-joining the conversation, “no this is not how standing arounds are meant to work. I mean not how stand ups are meant to work.”

Everyone was a bit disappointed because they thought they were doing pretty well.

So Zara explained , “A stand up is only meant to go for about 15 minutes, but this meeting is going on for a long time. And you are NOT meant to have coffees. The whole point is to be uncomfortable so you don’t want to be there.”

“Why would you want be uncomfortable or go to a meeting if you don’t want to be there?” asked Penny.

“So you only stay for 15 minutes – that’s also the reason a lot of teams don’t let the testers talk”

“What do you mean by that?” asked Alice.

“You have probably all heard of tester logic,” said Zara, “and you have to be very careful not to listen to testers in case they befuddle and confuse you with it.”

“And what do you mean by ‘tester logic’?” Asked Alice.

“Testers often talk about doing things that sound sensible but that nobody will really do. That’s called tester logic – things that sound like you really should do them but that you know your project team will not really do in practice. Thinking about it can cause you to get all muddled and upset,” said Zara.

“I’m not sure what you mean but Alice is allowed to talk in our meetings. We will just ask her to be careful with her tester logic,” said Penny.

“Thankyou,” said Alice, “but it won’t matter tomorrow because I am off at a tester breakfast so I will be late in.”

“That’s OK”, said Penny, “we can just wait for you.”

“No you can’t,” said Zara, “you have to have the meeting at the same time every day.”

That all seemed very strict. But the team eventually agreed to have the meeting at 10am every day in case people came in late.

“But how can we have a 15 minute meeting if we are going to talk about all the new practices we want to try to use?” said Peter.

“There is no try – do or do not,” said Zara. And she laughed a little to herself.

But nobody else laughed – they all just looked at Zara and waited for her to finish laughing.

“Sorry,” she said, “what I mean is that you can’t talk about all those things and get through the meeting in 15 minutes. So if you are in a stand up all you can talk about is what you did yesterday, what you are going to do today and what is in your way.”

Zara could see people were disappointed so she added “I know the practices are really important but maybe they can be in a different meeting.”

“That’s a good idea,” said Penny, “Lets have a standing around meeting at 10 O’clock every day. But it might be better to only have our practice meeting once a week so we can introduce one or two practices a week and have time to get used to them. So we can have have a practice meeting every Thursday when we will talk about whether we like the practices we are trying and what new ones we want to try.”

Zara began to say something but she was interrupted.

Bran came into the room and asked if she could interrupt. People often ask that, because they think it is polite, but of course when they ask it they have already interrupted people.

“Penny – you have to come to the management meeting. Steven is asking for updates on what all his teams are up to.”

“OK,” said Penny. She wasn’t sure what kind of updates she was meant to be giving but at least she could say they were having standing around meetings every day and that they were also going to do pear shaped programming and some practice meetings.

And so Penny headed off to her first ever management meeting and the team went off to the call centre to see what work they could help with.