He lists eight reasons why managers who don’t understand Agile might decide you aren’t committed to the project/company; I thought I’d review that list and add my personal experiences:
- You work only 8 hours a day whereas the committed people work between 12-16 hours a day.
This was the reason my latest gig was terminated, although the numbers were slightly different: I was “only” doing 10+ hours per day while others were doing far more. I tried to explain the concept of sustainable pace and was told “we don’t have time for that”. I also asked about the quality of work that’s produced when people are worked that hard; apparently quantity is more important.
- You seem to be wasting another persons time or your time all the time. Whenever you have been noticed by the senior management, either there is someone looking into your screen or you are at someone else’s desk looking into his screen.
The presence of individual cubicles can be a warning sign, but when I suggested a couple of people temporarily move to a room so they can work together on a problem I didn’t expect to be told that it’s “wasteful” – apparently the prefered method is to have one person write down their thoughts and the other then reviews/comments on that document. It was rare to see someone leave their desk to talk to a co-worker; email wasn’t just the preferred medium, it was virtually the sole method of communicating.
- You do not have a thick bunch of functional design document lying on your table.
I have always tried to maintain a clean desk policy (especially since working on military projects) and strongly believe that anything worth keeping should be kept somewhere central (and backed up). This means I rarely have piles of paper on my desk; I tend to read documents online, which also means it’s easier to know I’m using the latest version and not just the one that happens to be closest to hand.
However, this point (I think) is more about the “lack” of big design docs on Agile projects. I don’t understand how anyone thinks they can create a design (or a plan, for that matter!) for something that’s not going to be implemented for some months – either they have great foresight (in which case why haven’t they picked winning lottery numbers?) or are working on something so stale that it’s already out of date. That’s not to say there shouldn’t be an overall vision (or release plan) but that has to be coupled with the proviso that it may change at any point, right up to the last minute.
- You seem to be on the lookout for passing on the blame to the customer for your incompetency. You want to have the customer involved with your work every now and then. You want to show him what you have developed thus wasting the valuable time of the customer.
Fortunately this isn’t one I’ve encountered very often; I have been lucky enough to have customers (both internal and external) who understand the importance of their involvement and found the time to commit to working with the team. In all these cases, the customer has been very happy with the results. Having said that, I had a manager who didn’t understand why the customer should see anything until we were completely finished – she was scared to show work in progress. It’s obviously important that the customer understands what they’re seeing, but then that expectation should be agreed at the start of each sprint – if the team commits to delivering X in that sprint, then that’s what the customer should see, even if X is just a very thin (but functional) slice of the whole vision.
- You do not seem to know who wrote which part of the code. You always seem to defend the non committed people in your team by saying that the code is owned by everyone on the team. You do not seem to know whom to blame when a certain functionality on the system is not working well.
Apportioning blame seemed to be a big issue for some managers, in my experience; it’s not about knowing who to praise or reward, it’s always about blame and punishment. But the rationale behind shared ownership isn’t to hide the “guilty” – it’s about the whole team being responsible for delivering something which is potentially shippable. That means any team member can be coding, testing, writing documentation – whatever it takes to meet the definition of Done. This doesn’t mean that someone who has never written a line of code before is going to be let lose on the code base, but it does mean that someone whose expertise is in client-side (GUI) development may write some server-side code, or vice versa. It also means that people who, in a waterfall environment, are used to writing code and “throwing it over the wall” for someone else to QA may well find themselves involved in testing.
- You and the team that you work on do not seem to introduce heavy technologies into your project. It seems that you are not interested in learning new things.
Since when are “heavy” technologies are good thing? Surely a lightweight technology (or a combination of them) which achieve the same result are better? I guess it depends on how these terms are defined, but I would the think the best thing is to adopt whichever technology is appropriate (meets the project needs) and affordable in terms of implementation cost (mainly time), licensing (both development & end-user costs), etc.
Far from not being interested in learning new things, most members of scrum teams I’ve worked with have been keen to learn and instead are held back from exploring new areas by the direction given by architects and/or management. It would seem sensible (to me at least) that the developers are the ones who set coding standards and pick development tools, rather than having them dictated by someone who may not have written code in many years. Similarly those team members with QA experience should guide the testing process, and the technical writers should pick the authoring tools. Yes, management should be involved in these decisions but they should listen to the people who will actually be doing the work; if there is some overriding corporate direction that trumps these experts’ view then the managers need to share that rationale and understand the risks that their decision introduces.
- You do not seem to have anyone on the team who specializes in one thing. Everyone seems to be working on everything in the system.
I think this point is linked to #5 (shared code ownership) to some extent – the scrum team are collectively responsible for delivering potentially shippable product, so there’s a shared responsibility to have/gain the skills needed to deliver and yes, it may be that sometimes everyone is working on everything in the system.
One misconception, though, is that Scrum says there shouldn’t be any experts. The fact is there will (and should) always be experts, but they need to (a) share those skills, and (b) not confine their contributions to just those skills. I often drew a T to describe “ideal” team members – they have breadth across many skills and depth in some areas; the aim is not to have people who are solely broad (and shallow) or deep (i.e. very specialised).
The problem with having a specialist who doesn’t share that skill is two-fold: (1) the individual can “hold the company to ransom” and demand special treatment in order to retain his skills, and (2) if no-one can cover your role, you can’t ever have a day off! Obviously point 1 is how I would explain the need for skill sharing to the management team, and point 2 was how I sold it to the specialists who were reluctant to share.
The fear (mainly expressed by some developers) of becoming a “jack of all trades and master of none” is unfounded because there will always be the need for experts; however, having them as the only person with a particular skill is not good for them or the project as a whole.
- Every morning your team wastes everyones precious time by doing a stand up. Other teams are busy working in the morning hours when you guys are wasting time standing around each other, as if in a party.
OK, you caught us – we have a 15 minute party every day! With balloons and ice cream! No, of course we don’t – it is one of the few “ceremonies” that Scrum requires though. Ideally the team are talking to each other all the time and everyone knows what everyone else is working on, but realistically this is the daily opportunity for everyone to catch up. There are three simple questions:
- what have you done since the last stand up meeting (i.e. yesterday)?
- what are you going to do until the next one (i.e. tomorrow)?
- what problems are you facing?
I often ask the team to also mention any obstacles they’ve overcome, to give their colleagues an awareness in case they encounter similar issues.
Given an average sized scrum team of 8 people, that’s less than 2 minutes each to cover these questions, so the answers can be a little lacking in detail … but that’s OK because this is not meant to be a problem solving session. The aim is to keep everyone in sync, so that the team know what they’re each doing for the day and, if necessary, seek help or change a team members priorities. Any detailed discussion should happen outside of this stand up meeting, and as the Scrum Master it’s sometimes my job to remind everyone of these “rules”.
Fortunately I didn’t have to defend the idea of the stand up meeting. Unfortunately I did have to defend team members from an intering manager who frequently forgot that “chickens” can observe but not guide (or sometimes outright direct) the team’s discussions. When a team member picks up a task card from the To Do column and moves it to In Progress, the manager would sometimes tut or just put the card back … and then wonder why the team didn’t feel empowered!
Wow, that turned in to a much longer post than I anticipated; I hope it’s interesting and not just me ranting 🙂