The Agile Manager

There was no specifics around management in Agile originally, only for development approach – though addendum’s have been (hurriedly) added over the years. Management issues always existed pre-Agile of course, but over the last 10 years the role of “manager” has become a lot looser than of old. You can have a manager title, and have absolutely no power, responsibility or subordinates. Accountability and Responsibility are two things I believe a management role should have. If a manager doesn’t even have one of these things, what use are they? And why is management style so important on Agile projects, specifically?

1968: “Conway’s Law” is coined and summarized as follows: “Any organization that designs a system (defined more broadly here than just information systems) will inevitably produce a design whose structure is a copy of the organization’s communication structure.” It has long had the status of folklore rather than of well-supported scientific result, though recent studies have lent it some academic support. (The social aspects of software development remained largely ignored by academic software engineering until the mid-90’s.)

I have learnt a lot from looking backwards recently, as was reading some paper on Incremental and Iterative development (from the 1950’s!). Management is about dealing with human beings, so it should advance a lot further from the authoritarian attitude still prevalent.

Management is largely still based on “Theory X” (http://www.businessballs.com/mcgregorxytheorydiagram.pdf). Theory X is based on assumption that people don’t like to work, therefore have to be coerced/forced in to working. And without generalising too much, I would say that attitude is extremely common. And right there we have anti-Agile from the get-go. Whereas Theory Y is more pro-Agile, which promotes concepts as empowering and giving responsibility.

It’s so easy to sell Agile concepts and devise processes that look great – but by far the most mammoth task is the ongoing management. And you are right, Agile consultants (in fact many consultants) will avoid dealing with the management, instead focussing on individual tasks and processes. Managing Agile projects certainly was not for amateurs or “to play at” (and I have seen that too frequently). In comparison to older step-down approaches used on projects I used to be a tester on, I was shocked how fast and spectacularly, an Agile project could go wrong. Problems could be blamed developers, tor testers – but ultimately there is supposed to be someone in charge of the project timeline, and who is accountable.

Ignoring need for effective Agile management leads to: no transparency, poorly developed product, and subsequent finger-pointing. That sounds like the anti-Agile!

Advertisements

The Agile Test Contractor

I have been in many companies, and if there is a cohesive experienced Agile project team, things can happen, with or without formal process.  And majority of the time, it’s contractors providing this level of skill.   If all know their roles, observe good Agile development practice, and happy to extend beyond their remit when necessary, that is a good start in any Agile methodology.  Agile testing … is it different?  The fundamentals should remain – strategise, plan and script. But there are other focus areas such as test automation and exploratory testing* which are essentials.

Continue reading

Should you trust any testing company with “test” in their company name?

I have to say a no – why? The mere fact that someone decides to put “test” or “testing” in their company name just rings alarm bells to me. Putting asides agencies that rebranded themselves as test consultancies, there is also a ramp of companies in general, purporting to provide testing services. Each claim to be a leader in their fields (usually every type of testing you can name), and very few actually provide a service, simply bodies – testers, maybe test manager, but largely people who test.
Continue reading

QA Chaos Management

A lot of developers would prefer to be out-of-range of testers – if you want to get into testing, then be prepared to justify your existence by any means necessary. Developers are awash with different types, from geniuses with Aspergers, to self-taught amateur with insecure chip on their shoulders. It’s not your job to judge, it’s to adapt – testing is always about adapting, and in some ways mirrors the demands of a developer career. But without us in QA, the SDLC can descend into a private club, excluding those perceived as “in the way”. It’s a fine line between squashing developer creativity, or allowing developers to run amok. Of course a decent Scrummaster should prevent this, but we are in the real world here.
Continue reading

How Agile becomes fire-fighting

What is the obsession with saddling people with combined roles in Agile – and often they do not even know they have two – it’s assumed. The project manager was split into two roles – Scrummaster and Product Owner. I do not believe there was anything wrong with the role of project manager, but the Agile division made sense utilizing development management skills of planning and maintaining momentum, with the (assumed) business analysis and planning skills of the Product Owner. It makes sense on paper, but with the splitting of roles, comes more risk as you have to have the right two people. Very often the Scrummaster or the Product Owner falls into project manager role, due to weakness in one or the other.

In industries still early to Agile, they retain the usual Waterfall role structure, though development managers have become a rare sight. This actually doesn’t have to mean a disaster – the Agile roles are still fulfilled to some degree, although the Scrummaster/Product Owners are recombined into a project manager. In those circumstances the Project Manager will have a stressful time – and highlights that there is a good reason for the PM role split. To work in a Agile fashion is more demanding on planning, and it’s a bad situation if the project manager is spending 95% of his day on MSProject (or something less hideous).

Even worse scenario is when the Scrummaster and Product Owner roles are “missing”. Either through inexperience within the team, or people rejecting their roles by simply not performing them. Sounds strange? Look in any corporation and you will find this situation. The onus is that situation is that the developer(s) understand what is required to deliver an Agile project. But the stress this time is firmly in development camp – just the place where you not want a stress-overload. You will end up with a project that bounces around (and largely on the spot).

Comining roles can sometimes be sensible business move, but in Agile the roles are seperate for a reason. Ingore them, and dont’t even think “we’re agile!”. At best you will end up with a faster Waterfall struggle. If you are struggling to fill roles effectively, then maybe the methodology isn’t for you … not without changing your approach.

Agile is not a replacement for thinking

Why do I hate Agile? The same way I am irrationally hate Microsoft and Apple? Well, close, but my mentality is a little more culture-based. My resentment of Microsoft is largely down to the abominable software. Apple may do it in a slicker and prettier way but the same proprietary software hell-hole as Microsoft. Regards Agile … I am English, so by default root for the underdog. I was drawn to Linux because this was first case I had seen of opensource in action. Software designed with passion rather than for demand. Technically brilliant, usability flawed – but still improving. Agile is in same bracket for me – a group of people deciding to do things in a better way, and challenging previous methods of doing things. And much maligned and misunderstood. I can only talk from UK perspective of course, but Agile’s arrival signalled a wave of buzzword frenzy around the subject – it had perfect soundbites for its unofficial salesmen.

Agile wasn’t sold to us – we adopted it. It is easily sold as it not dictatorial, and focussed around the importance of the team, and the processes behind it. It made sense to people. But then did it. In principle, in diagrams, in sound-bites it sound clear and logical. I mean, who could argue with more stakeholder involvement, more communication, organised sprints, adaptive planning, rapid development. No-one – but as with any method, its in the application. And mostly its in the team itself. More communication, people can manage – but its needs structure, it doesn’t happen organically; human beings slip.

First major, and I mean major, booboo was Agile weakened the project manager role. There was a thorough misunderstanding of project management in Agile, and in earliers days it was less clear, as Agile Management evolved a little later than the original Agile definitions. Project managers still existed on Agile projects, but generally less powerful. Power had shifted too far to development, which meant those outside the core SDLC were looking in rather than involved.

Over time this weakness was realised – and Agile was blamed. Why, I do not understand – people made assumptions, followed, realised error, then blamed Agile for putting them there to start with. So SCRUM become more prominent, with its clearer focus on the management side. Again clear diagrams, simple explanations, how could you go wrong? Well, just bacuase you fill the roles, it doesnt make the process magically work.

Waterfall has been slated so much, its become some kind of pariah – Agile is evolution not replacement. Now people are paying the price for that arrogance, and treating Agile the same way. A CEO at a Startup I was comntracted at last year, whined to me one day “the process isnt working, you are supposed to be managing this!”.
“How do you mean, its not working?”, I replied.
“It just isn’t working!”.
“So what is missing for you? All the issues and tasks are in there, assigned to Sprints”.
Of course, silence. Because he didnt know the first thing about having a project process, he was used to people just jumping when he complained. He liked the idea of SCRUM, but in hindsight, he expected it to mean he didn’t have make effort in the process. He was effectively the stakeholder, but behaved like a cavalier project manager. And let the largely weak development team do what they liked (who struggled with such lofty concepts as source/change control – but I dont expect much from flash/flex developers). The CEO was also expecting someone to wipe his proverbial rear as he lumbered along.

SCRUM is not an island

SCRUMIn 1986, Hirotaka Takeuchi and Ikujiro Nonaka described a new approach to commercial product development that would increase speed and flexibility, based on case studies from manufacturing firms in the automotive, computer, photocopier, and printer industries.[1] They called this the holistic or rugby approach, as the whole process is performed by one cross-functional team across multiple overlapping phases, where the team “tries to go the distance as a unit, passing the ball back and forth”.

The first time I encountered SCRUM in 2001. The development manager was utilising pair-programming and daily standups. The project failed, largely through chronic mistakes made with market analysis. But it did introduce me to a new concept of telling a group of people what I had been doing, and what I was going to do. Just a simple idea, as all the best ones are.

SCRUM has been inexorably tied up with Agile methodology, but it predates its formal manifesto (2001). It addresses a key problem in projects, which is momentum. All human beings need a reason to do something with full committment. Deadlines are there not only for clients, but driving a project forward to a known point in time. So it logically follows that the deadlines of releases also will create momentum towards the final goal. The concept of daily meetings is again, not new. These short daily standups keep a project on track, but all involved knowing whatever anyone else is doing, and allows a forum where blockers and other concerns can be raised.

Planning on Agile projects are challenging, given the short increments, and the necessary connstant reviews and changes that are inevitable. SCRUM is largely focussed on this area of project (Agile on the software development process). Because of Agile’s driving focus, which is rapid iterative software development, it needs as strong process that is enforced. SCRUM addresses the project management side of Agile, devolving the role of Project Manager in Product Owner (or Product Manager) and Scrummaster. What SCRUM includes in its roles are:-

  • ScrumMaster – who maintains the processes (typically in lieu of a project manager)
  • Product Owner, who represents the stakeholders and the business
  • The “Team”, a cross-functional group who do the actual analysis, design, implementation, testing, etc.

Notice the last role? It isn’t a role at all, it the people who make SDLC happen. This is where Agile steps in. If the Scrummaster is weak, then you might as well drop SCRUM to start with. Too often with SCRUM, the focus is on it as a development solution rather than a project management one. Agile and SCRUM require radical rethinking of planning, more change than most traditional project managers can handle (hence evolution of Waterscrum and Scrummerfall).

Its an imperfect world, and Agile projects generally do partly succeed, but a lot depends on the team you have. In fact if you have the right team together, then methodology is virutally inconsequential. A good developer knows the importance of the testers, and also the stakeholder. This should be a mutual respect, and makes for a very cohesive team.

Maybe just my opinion but there is something always omitted from Agile planning which is pace of momentum. To drive your project team into the ground, simply try and apply same pace all the time. Human beings work better in a slingshot fashion – slow build-up leading to more powerful movement. This is the way to operate Sprints, not by Sprint just sliding into each other release after release. I thought it was just me and my quirks, but people respond better and more consistently when there is time to reflect, learn from, and feel proud of what has just passed.