16

Consider a company that is proudly certified for some non-Agile methodology, uses it as a selling point to its customers to demonstrate accountability.

How do you go about introducing Kanban or Scrum progressively without breaking their whole system and still making them confident that it can still be just as accountable / auditable?

I know this is possibly related to "How would you introduce an agile methodology like Scrum", but here I am wondering about ways to circumvent/work around the fact that the company imposes a certain way of managing the SDLC under the false pretense that it's the only way to have an audit trail.

Community
  • 1
haylem
  • 28,856
  • 10
  • 103
  • 119
  • What is the certification? Is it ISO-9000? – Robert Harvey Dec 13 '10 at 23:57
  • 1
    You're a little light on details; if the certification requires a certain minimum level of artifacts to remain certified, and the company has already tightly mapped those artifacts to your dev process in a way that minimizes impact, then there are no workarounds. – Robert Harvey Dec 14 '10 at 00:03
  • @Robert Harvey: an ISO-9001 would be a good example. Anything that needs auditable requirements and tests specifications and traceability to document and task owners. – haylem Dec 14 '10 at 00:09
  • @Robert Harvey: Yes, but a mapping just needs to be auditable. As far as I can tell, most issue/defect/task/bug trackers can be part of an audit trail as they record ownership of a task over time. And can even be linked, in the case of software development, to an SCM for tracking revision numbers as well. Plus you can use your tracker to identify requirement, f-specs and test IDs as well and get your traceability matrices from there. – haylem Dec 14 '10 at 00:10
  • @Robert Harvey: especially considering the tracking for an ISO-9001 is not that hard to get and maintain, but somehow often seems to be seen as something that needs to be horribly redundant and verbose. – haylem Dec 14 '10 at 00:12
  • @Robert Harvey: I know it might seem like I sort of try to answer my own question here, but basically this seems to make sense to me and even concur with what I have been taught and have seen in some environments, but I'd like to have other opinions. If you want to apply the question to another certification that matches your domain, please do so, I'm interested as well in any case. – haylem Dec 14 '10 at 00:14
  • We are ISO-9001 certified. We have a development model that maps to artifacts in the ISO-9001 standard; it is deliberately designed to be as lightweight as possible. We seem to have no trouble with the auditors; in fact, they like what we do. It is a custom agile methodology, similar to XP but only incorporating some (not all) of its elements. – Robert Harvey Dec 14 '10 at 03:38
  • @Robert Harvey: oh I agree with that: auditors I've come across usually like it when they encounter something that doesn't add useless stuff just for the sake of it and when they don't need to sit through all your piles of docs (and shoot yourself in the foot because one duplicated matrix doesn't match another one). – haylem Dec 14 '10 at 14:12

5 Answers5

11

I think it's a myth that Agile project teams don't document their applications and this is the first point of resistance you get in companies that are certified to have the best documentation as per their standards.

I work in an ISO-9001 certified company, but we ALSO do Scrums on a large number of our projects. In our case, the change came in from the Project Delivery heads (i.e. quite senior folks) and that's why it gets adopted - as opposed to a Project Manager or Developer trying to push in this change.

One useful practice we follow is Document Enough but Continuously . This obviously means we do not follow all the templates prescribed for the project, but there is a conscious understanding and agreement over which sections/documents are needed vs those that are just pointless overheads.

You'd then need to socialize this point of view and get the approval of the Quality group or Standards division or whatever it's called.

The Agile principle is 'just enough' documentation. Can you try and push it from the Customer to express to the team how much is just enough? The project manager could talk to the customer and understand what their expectations and organizational needs are and then both document the decision and meet those expectations. If it's good enough for them (i.e. the paying customers), then it can be what you follow.

If they think Agile doesn't scale up to large projects, convince them it can - by decomposition and parallel effort.

In large organization, control and oversight for large programs are accomplished by running a Project Monitoring Offices (PMOs) that conduct conventional planning for costing/accounting/resource management etc - hence they demand a lot of documentation, but they can monitor progress using Agile practices (the SCRUM burn-down chart for one). They need to know how techniques such as continuous integration help them earlier rather than later, and hence it's better for everyone's productivity to get overhead docs out of the way.

Agile is a set of skills that a team can learn which is largely orthogonal to our traditional technical skills. But if you add this to their existing skills, of course you can become a more effective team. Daily standups (i.e. Scrum meetings) are not going to be possible overnight - but you would have regular team meetings (say bi-weekly) at present? I'd say start by converting those into following the Scrum question agenda (not too sneakily ;) and convey to the wider team why this approach can work and does not mean lax documentation / poor standards or whatever other myths.

JoseK
  • 1,407
  • 12
  • 22
  • While other answers were good, I thought yours was the one trying the hardest to address the specific question, not just giving general hints on using agile and trying to figure out why we'd want to use it. Good answer. Thanks. – haylem Dec 20 '10 at 22:15
  • @haylem: glad it helped. in our case, we appointed a keen team member the Agile Champion to facilitate the transition. He made all of us aware of a lot of this stuff. Maybe you could volunteer for such a role. – JoseK Dec 21 '10 at 06:34
8

I'd separate Scrum from Kanban first.

With Kanban - and here's a pretty good source on how to do it right - the principle is that you respect the exiting process when you start. Kanban is not what you replace the existing process with, but what you apply to it. Map it out, visualize, and set up certain conditions for gradual improvement.

Scrum is fundamentally different in the sense that it is something that is going to displace the existing process.

A team that is used to 12-month (or longer) waterfall SDLC cycles is going to have a very hard time transitioning to Scrum. Gradual shortening of the cycle to 6- or 3-month release trains with smaller scope could be a useful intermediate step.

azheglov
  • 7,177
  • 1
  • 27
  • 49
  • I like the idea of respecting the existing process. I am not sure about the gradual shortening though, it may provide some pain without much benefits. I would go for the senior management buy-in and then a few weeks getting folks used to the agile process of daily scrums and two week iterations. – Michael Durrant Mar 07 '12 at 03:00
6

Like any new thing you will try to introduce to an organization, you will face strong opposition. Are you ready to be criticized and be the responsible if it fail? You have to be a strong person. That's the price to pay when expose yourself.

  • Ask yourself why you want to use Scrum. Do you need to solve a real problem?
  • Ensure that YOU are committed to it, because nobody will do it for you. You will be the owner of the thing. At least until it brings positive effects in the organization
  • Train yourself. Books and internet is not enough. Go to a course first, or you will increase dramatically your chance to implement Scrum incorrectly. Which will probably lead your team to worse results than before
  • Sell it to the team first. You must have their full support, obviously
  • Don't propose a change, propose a test. And consider it like that. Scrum may not be suitable to your organization (or to your team)
  • Find a sponsor in the top management
  • +1: "Ask yourself why you want to use Scrum. Do you need to solve a real problem?": Very good point. Before introducing a new way of working one should ask what it tries to solve. Unfortunately, introducing SCRUM (or any other method) to solve non-existing problems will just create overhead and lower productivity instead of increasing it (I speak from direct experience). – Giorgio Nov 11 '12 at 12:39
3

This is almost exactly what happened at our company. We followed strict, non-agile methods. When a new Lead Technical Manager joined, who had some experience with SCRUM, he thought it would be good to try it out.

The way we did it, was to take a small group of developers (and analysts) to make a pilot SCRUM team. We followed strict SCRUM methodology for about 4 months, after which the company reflected on what we have done, how we did it, analysed to data (you know, all the stuff the BA's need to do).

What they found was that the pilot was a great success. So they made another team which follows Kanban, and they too have been a great success. I think there is talk that the rest of the developers also forming SCRUM/Kanban teams.

I think the pilot was pivotal. It gives the strict side of the business time to evaluate and see that it works first.

Nico Huysamen
  • 1,181
  • 9
  • 16
1

I'm a Agile coach and one of the keys to change initiatives is buy-in at all levels! This includes executives, development teams, managers, ...etc. Before announcing a large or small change effort I would suggest getting individuals on board with you first. Doing this through a third person conversation is the easiest way for individuals to start cranking on new ideas. What is third person? A blog, youtube video, presentation, ...etc. This way those folks can start coming up with their own ideas and with your influence will jump on board with a change initiative.

Here are two crafty videos I have used to spark interest at all levels in the food chain.

Kanban: http://www.youtube.com/watch?v=0EIMxyFw9T8

Scrum: http://www.youtube.com/watch?v=Q5k7a9YEoUI

KanbAnimation
  • 11
  • 1
  • +1 for buy-in, especially given the comments in the question showing lack of buy-in. – Michael Durrant Mar 07 '12 at 03:02
  • @KanbAnimation: I think you should first ask yourself if SCRUM is good for the company in which you are trying to introduce it. (From my direct experience) SCRUM is not better for all kinds of projects and introducing it does not **always** make a company more effective. Convincing executives (that might lack the technical knowledge to understand the consequences) to introduce SCRUM might in the long term damage the company if SCRUM was not a good fit for the kinds of projects they were doing. – Giorgio Nov 11 '12 at 12:43