Interview with Madhur Kathuria

Madhur Kathuria has coached nearly 300 teams for almost 75 clients across the US, Europe, South East Asia, Malaysia and Thailand. In this interview he talks about some of the cultural challenges for agile adoption. Read it here.

Interview with Elena Yatzeck

Elena was Chief Agilist for JP Morgan Chase Treasury Services and is now a VP of Corporate Compliance Tech. Find out how JP Morgan Chase reconciles agile with compliance and risk management demands. Read it here.

Wednesday, August 27, 2014

Are Certifications Important For Agile Transformation?

One of the greatest impediments for agile transformation is obtaining the new skills that are needed. (In the article “The Top Impediments To Agile Transition”, skills are identified as impediments 13 and 17.) It is therefore important to understand the role of certifications in recruiting for (or training for) the required skills.

Are there certifications for the skills that are most important?

The first question to ask is what skills are needed?

In my personal blog post today, “To Be Certified – Or Not?”, I share some of a discussion that occurred recently in the LinkedIn group “CIO Network”. In that discussion, many participants posted that the critical skills that are needed for IT workers are not technical, but rather are “soft”. These were variously described as “foundational skills”, “employee skills”, and “natural learner” skills. They tended to focus on the ability of people to learn new things quickly, to get the job done, to work well with others, and to have a strong work ethic. These are things that cannot easily be certified.

What about technical skills? – such as Certified Scrum Master? PMI-ACP? Coaches and “scrum masters” with these certifications are often brought in to help teams to learn agile methods, and to work with managers to help the transition to more agile friendly business processes. The latter type of coaches are sometimes referred to as “agile transformation coaches”.

The core rationale for bringing in certified coaches and scrum masters is that they have a well defined set of knowledge that can form a baseline for the organization as it transitions to agile. This rationale rests on the assumptions that:
1.    The certification is indicative of the person’s actual knowledge.
2.    The certification is relevant to the Agile practices and values that the organization needs.

Are these true?

It is not clear to me that these things are generally true. For example, if someone has an Agile certification, it is usually either Certified Scrum Master (CSM) or PMI-ACP. I have taught Scrum – as a two day course – (even though I am not Scrum certified) and I can tell you that in two days, one can only obtain a glimpse of what Agile is about. Further, Scrum emphasizes things that are very different from other methods such as eXtreme Programming (XP), Kanban, and Feature Driven Development (FDD). As such, someone having a CSM certification does not really tell me anything useful: it does not indicate to me that they are sufficiently mature in their perspective and experience to be trusted as a teacher of Agile methods.

The PMI-ACP course is a little different in that it is not specifically focused on Scrum, but the PMI-ACP course that I took was very Scrum centric. (I am not ACP certified because I did not do the paperwork.) The course was three days, and while it was a really excellent course – developed by the people who developed the PMI-ACP course – someone taking only that course would still very much be a “newbie” with respect to Agile. That said, ACP requires one to have actual experience in order to qualify: I contend that that experience is the real value.

Agile is not something that you can learn in two or three days. To really understand Agile, you have to have a pretty substantial career of software development behind you. In fact, I feel that it was my own experiences during the 1980s – before Agile existed – that enable me to truly understand Agile. During that time, I saw what worked and what did not work, and I therefore see Agile as a rejection of what did not work, and a return to what did. I see Agile not in terms of strict practices such as standups, but rather in terms of a set of values: focusing on what really matters and not on things that don’t actually matter, working incrementally in small chunks, elaborating a design as you go, and having continual communication among team members. A course in an Agile methodology can help one to think these values through in the context of that methodology, but one could just as easily do that by reading a book. What matters is the background of experience that helps one to put Agile into the proper perspective, so that it can inform one’s judgment.

Is certification relevant to the practices and values that the organization needs?

Organizations that bring in certified Agile coaches are essentially choosing to base their Agile adoption around Scrum. This is because Scrum certifications are by far the most dominant. Even the PMI-ACP is quite Scrum-centric. Yet, I have found that Scrum is not always the best approach for organizations with legacy processes and skill silos – at least not as a first step. If you bring in people who are certified in Scrum or a Scrum-centric concept of Agile, then be sure to also bring in some people whose primary focus has been XP, Kanban, FDD, or some other Agile approaches: that will add balance to the discussions about how to implement Agile.

All of these methodologies – except for XP – focus primarily on process, yet much of Agile is very technical. Agile coaches often refer to the “technical practices” of Agile: these are things that are emphasized by XP, and by DevOps: things like automating software builds, automating software testing, and automating deployment. (Yes, I know that DevOps is about more than just the technical practices.) These technical skills are in relatively short supply, and yet they are critical, because without automation, it is very difficult to meet the two week iteration cycle that is so prevalent in Agile projects. Without automation, what tends to happen is that testing gets chunked up – turning the Agile iteration into a mini “waterfall” project. DevOps is impossible without automation – and some say that DevOps is the “new Agile”. Automation is critical for Agile; yet the technical practices of Agile are not supported by certifications: tools such as Jenkins, Cucumber, Selenium, Vagrant, Chef – these things are not covered by the Scrum Master or ACP certifications. Further, seeking skills in specifically these tools is foolish, because these are only a smattering of the tools out there, and that mix of tools will surely change by this time next year. It is far smarter to find people who are experienced with a range of these tools, and who are adept at learning new tools. Thus, you want to find self learners – and self learners are often too impatient to sit through a certification course. Some of the best people who are self learners – people like Bill Gates, Steve Jobs, Michael Dell, Larry Ellison, and Mark Zuckerberg – did not even wait around for their college degrees before they sought to implement their ideas.

Do certifications help you to get the best people that you can get?

Many people who have Agile certifications claim that those certifications have been beneficial for them, by adding focus to their work. They found that the certification process helped them to think through their prior experiences and put them into perspective, and provided a conceptual framework for thinking about issues. That clearly has value: while I personally would prefer to obtain that by reading and trying things on my own, not everyone is like that, and if certification works for someone, that is all that is important. What gives the certification value though, is that the person has substantial prior experience so that the certification learning content has context: it helps the learner to organize their knowledge. I therefore propose that a two or three day certification course does not itself represent substantial knowledge of its own: it merely provides a framework for prior knowledge.

If you accept this proposition, then you must conclude that certification does not provide any kind of metric about the quality of someone’s knowledge. Certification does not prove advanced knowledge: it only proves that someone has been introduced to the most rudimentary concepts. It should therefore not be a criteria for finding the best people: only for finding the lowest common denominator. Consider this anecdote: In the article, Why Einstein Was Not Qualified To Teach High-School Physics, Charles Wheelan shares this story:
“My wife Leah graduated Phi Beta Kappa from Dartmouth. She was a computer science major with an emphasis on math. She worked in the software industry, built a company, and then sold it. She seemed, in every respect, perfectly qualified to teach middle-school math. She found a job at a school adjacent to a public housing project on Chicago's South Side. On about day three of that job—after she had met the students, decorated the classroom, and started teaching—the principal informed Leah that she did not have a ‘middle-school math endorsement,’ which the State of Illinois requires.”

Are we doing the same thing with Agile certifications?

Monday, August 18, 2014

Do not constrain projects with detailed up front requirements

My prior post promised to look at the root causes of the obstacles that I mentioned in my July 25 post. So let’s do it!

The first “stumbling block” was, “Need to not constrain projects with detail level objectives.”

Have you seen this happen? For example, have you come across “agile” projects that were given a detailed requirements document and then told to “do it agile”? Have you been on “agile” projects in which there was a detailed feature list with hard dates for when those must be delivered? That’s what I am talking about here.

Direct Causes

Why does that happen? It depends. Sometimes it is the result of the project sponsor – typically a business area – that charters a consulting firm to research and document the system requirements. Other times it occurs because the organization has an SDLC that mandates that a requirements document be done up front. In US government agencies the SDLC is often rooted in procurement policy such as “CPIC” (see also this article), which treats software development as an “acquisition” as if the agency was buying a “thing” – but custom software development fits very poorly into an acquisition model.

Root Causes

Here is where we start to ask the “five whys”. Why do business areas ask consulting firms to perform an up front detailed requirements analysis? Some possible reasons are:

1.    That is how they have always done it.
2.    That puts them in control of the requirements – giving them a false feeling of confidence that all of their requirements will be met.
3.    When they initiated the requirements analysis, they did not know that they would be using agile methods.
4.    They just don’t know any better: they don’t understand agile well enough to know that an up front requirements analysis is wasteful.

Number 1 seems pretty straightforward: there is no root cause for it – or is there? The root cause has to do with human nature and might be somewhat spooky. Have you heard of the “five monkeys experiment”? Check it out here. Even though this experiment never actually happened, it gives you pause for thought.



For numbers 2 through 4, we do not yet seem to be at the root causes, so let’s ask,

2.    Why does a detailed requirements document make them feel more in control than the agile process does?
3.    Why did they not know that they would be using agile?
4.    Why do they not know agile well enough so that they understand how requirements are done using agile?

Before investing time to address each of these with an actual client, you should speak to the stakeholders – in this case the business areas that tend to create up front requirements – and ask them frankly why they do it. They might give you honest answers, but whether they do or not, you should be able to piece together the real reasons if you talk to enough people.

“The most dangerous phrase in the language is ‘we’ve always done it this way.’” – Real Admiral Grace Hopper

 Once you know what the real reasons are, you can plan to take action to address the root causes. For example, if it turns out that some business areas obtain a sense of control from having up front requirements, then you can endeavor to educate them on how agile puts them in control, by enabling them to evolve the requirements throughout development. Make sure that you work things at all of the levels or parts of the organization that are driving the behavior: in this case, it might be business area management and IT portfolio management.

While doing this, be sure to address the direct causes as well: the fact that business areas initiate up front requirements efforts. Try to intercept these efforts, perhaps by asking IT portfolio managers what business areas are planning new work. Become familiar with the pipeline of work, including the work that has not yet been funded or even requested.

Understanding root causes is an important step, but knowing what to do about them is not always so clear. For example, you might find that one root cause of some problems is that employees are not staying current with the latest techniques. What do you do? Some people are natural learners: they will read up on things – all you need to do it point them in the right direction (or even better, include them in your analysis process so that they help to figure out the root causes and what the “right” direction is!) On the other hand, some people are not as inclined to learn new things on their own. Thus, the right strategy depends on the personalities of the population that you are dealing with. In a future article I will talk about personality assessment, and more inclusive methods for finding root causes and defining solutions.

I have presented possible actions for root cause 2 – I’ll leave 3 and 4 for you.

We had another direct cause that we have not peeled apart into root causes: when an SDLC or procurement policy mandates that a requirements document be done up front. If there is no policy but the current SDLC defines a requirements phase, you need to work with IT management as well as business stakeholders to get the SDLC changed, possibly by defining an “agile version”. This might not even be necessary if agile projects can be granted exceptions from the SDLC. On the other hand, if policy defines a requirements phase, the task might be far more difficult, because you might need to involve senior management. In a government organization, this might require that the CIO “tailor” the applicable procurement policies.

Either way, you have an education task ahead of you. Simply defining new rules will not accomplish your goal of preventing business areas from defining requirements up front. You need to educate them. Business area managers and portfolio managers are generally very senior people, and they are not usually likely to attend a course that you create, so you will likely have to meet with them one on one or in small groups, and manage as a kind of discussion where you present key ideas and they get to ask questions about how it would for their teams, and how it would affect other things they are responsible such as their budgeting process. You will need to have answers for these questions: do not go in cold. By the time you sit down with these people you should have done your homework on what all of their challenges will be, by talking to their staff and by asking those who are on your side, such as your CIO.

In a future post I will talk about the need to assign team resources early – before work on a release begins!