Checklists reduce the likelihood of you forgetting to do something important and so increase the chances of delivering quality that will delight your customer. That’s a bold opening statement, it sounds more like a conclusion, but read on, please.
This begs the question, if my brief opening summary is reasonably correct, why does there seem to be a general lack of checklist use in software production? When I have raised the idea of checklists with colleagues none profess to using them (or using them in any consistent way for any length of time). There do seem to be some sectors where checklists and development go hand in hand, but why is this not a more general practice? When I tried to introduce them in to a test team some years back I could not get the idea to gain traction. I won’t deny that part of that could have me being a poor salesman rather than the idea being a poor one. Never the less none of the testers seemed to intrinsically see them as useful.
Checklists make sense to me. There are very few days where I don’t plan what I need to cover in a day. You might call that a daily plan or a “To-Do” list but it is just as easily viewed as a checklist. Checklists provide a level of comfort that the things I should be doing are getting done. I don’t list everything, just the important things, the things that I do need to complete on the day. When I sit in an aircraft I’m really hoping the Captain and First Officer are calling through those checklists. Wheels down landings at appropriate speed really appeal to me (my full list of requirements in this space extend beyond a single aircraft configuration). It was really my interest in aviation that brought checklists to the front of my thinking.
Pilots have checklists for the following: “before start,” “after start,” “before takeoff,” “cruise,” “pre-descent,” “in-range” (about 10 minutes before landing), “after landing,” “parking” and, if the airplane is finished for the day, a “termination” checklist must be completed. Checklists are fundamental to the aviation industry, the most regulated industry I know, because they virtually eliminate mistakes and oversights. In addition to mechanical checklists mounted in the cockpit, we consult plasticized checklist sheets and electronic ones displayed on airplane computer screens, as well as reference checklists for such procedures as de-icing (courtesy of Air Canada , the bolding is mine).
The use of checklists extend beyond aviation. Medicine, in particular surgery and critical care, has also adopted checklists.
The concept of using a checklist in surgical and anaesthetic practice was energized by publication of the WHO Surgical Safety Checklist in 2008. It was believed that by routinely checking common safety issues, and by better team communication and dynamics, perioperative morbidity and mortality could be improved. The magnitude of improvement demonstrated by the WHO pilot studies was surprising. These initial results have been confirmed by further detailed work demonstrating that surgical checklists, when properly implemented, can make a substantial difference to patient safety ( British Journal of Anaesthesia again the bolding is my work).
One of the things I really like about scrum is the Definition of Done (DoD). Why so? Because it is a checklist that the team must make each other accountable for. That checklist represents things that must be done in order to say we have value that can be delivered to our client. It removes the “hey did we complete the code reviews on that release?” scenario as the release flies out the door to client land. It covers off the “did we complete the testing we committed to?” panic question after release to a client (this does assume proper use of the DoD. A checklist to ensure proper use of checklists is probably a step too far). The DoD is a powerful governance item. The team I work with has it’s own DoD defined in key areas of story card movement and each of those stages has key attributes we believe are vital to ensuring consistent quality. The DoD sits on each team members desk and a big copy of it sits blu-tacked to a window in our area. It’s as visible as we can make it to the team and external stakeholders.
So what are the qualities of a good checklist? Or maybe a checklist is a checklist is a checklist? Just make something up and go for it. A checklist isn’t just any list of things, if you want it to be effective.
Here’s a nice article about what makes a good checklist. The key point summary:
If you are interested in learning more about checklists you might like to grab a copy of The Checklist Manifesto: How to Get Things Right by Dr. Atul Gawande. The good Doctor saw value for checklists in a number of endeavours, including software development. There are a few extracts and overviews of this book on the web if you would a bit more detail before handing over a few dollars to a book retailer.
I’m going to close out this article by
stealing borrowing from an Aviation Week article that quotes Dr. Gawande.
“….overcoming historic ignorance is less of a challenge in the field than ineptitude, the “instances the knowledge exists, yet we fail to apply it correctly.” While there is bountiful information available to medical professionals and most study for years to master their skills, the new challenge is to assure they “apply the knowledge . . . consistently and correctly. We have accumulated stupendous know-how. We have put it in the hands of some of the most highly trained, highly skilled and hardworking people in our society . . . . Nonetheless, that know-how is often unmanageable. Avoidable failures are common and persistent.” Disciplined use of checklists “provides protection against such failures.”
While the above specifically references medicine, change the reference to software development and I think the message still rings true.
I’d be interested in any feedback about instances where using a checklist has help improve and sustain software development quality.
As always, thanks for dropping by and having a read.
This is not an expose on #NoEstimates. It is not an appraisal of strengths and weaknesses. There are a bunch of people that write very eloquently on these aspects. It is not a recount of disagreements with those that oppose the hashtag (and how unsavory it can get – less said the better) . This is just a simple story about #NoEstimates and me.
I can’t precisely remember when I first encountered #No Estimates. I can’t remember how I first got alerted to the hashtag. I do know that it was a little while ago and the hashtag did two things. It caught my attention and it also triggered a thought of “I don’t think so”. That thought was not because I don’t like the idea of no estimates, I do, I really do, but the commercial realities I have dealt in, currently operate in, put the notion in the “highly unlikely” category.
Since first stumbling across the no estimates hashtag I’ve done heaps of reading on the subject, tweeted more than I can count and met, via Twitter, some really smart, respectful people. Woody Zuill, Ryan Ripley, Zach Bonaker, Vasco Duarte, Luis Goncalves, Neil Killick, the list goes on. Just about everyday I make a new connection with another friendly, smart person through #NoEstimates. #NoEstimates has actually had me reading books, articles and blogs that once I would have let pass by in favour of other sources of information. It has broadened and added depth to my knowledge and thinking. If this is all #NoEstimates delivered to me then I could hardly complain. But it runs deeper than that.
I read the beta book, provided feedback. Promoted it to work colleagues. I even presented a brown bag session on key take away messages from the No Estimates book (and from memory there was some interest, from some colleagues, in the possibilities). One of my colleagues ran a card count exercise across a couple of sprints and we compared them to the estimated story points. The team I work in did the same. What did we find? On only a relatively small amount of data card counting told us as much about the work that could be completed in a sprint as estimating. That was cool, and useful. That was a direct result of the beta book.
Once I started reading about no estimates I’ve never thought of #NoEstimates as meaning no estimates, at all, ever, in any context. I’ve always thought it spoke at broader levels, wider topics with a focus on improvement. To me there are key messages, things that I can try and bring to my workplace. #NoEstimates, to me, talks about:
There are many sub themes hanging off the above list. I’ve had conversations with people (face to face and Twitter) about #NoEstimates and these themes always surface. So, if I’m missing the point, I’m missing it with a lot of other people. I struggle to see how embracing any of the above themes could do anything but good for a company.
There is a further theme that calls out to me from #No Estimates – obliquity. Again, I’m not really clear how the heck I stumbled across the concept. I do know it involved this article. Obliquity is the notion that complex problems, with multiple moving parts, are best solved obliquely rather than directly. I don’t want to spoil a good article by saying much more (and I highly recommend John Kays’ book Obliquity). You can also catch him in a Ted talk . When I look at many of the problems spoken about in IT, and I look at the #NoEstimates themes I see an oblique approach to making those big problems better (such as sustainable quality, happy engaged people and highly delighted clients).
The company I currently work for will never embrace no estimates (guess I shouldn’t say never but it’s safe to say it would be a long time in to the future). There is a strong commercial model in place that mandates estimates. There is no scope for that to just stop. It is what it is and it is beyond my direct control. However the discussion around, and the lessons from, #NoEstimates provide ideas that could help our estimating process become more meaningful, our quality higher and our stakeholder relationships more valuable . It provides scope for experimenting and discovering and improving. At least that’s my hope.
Once again, thanks for dropping by and having a read of my thoughts.
I’ve noted in a few of my posts that the company I work for is undergoing a transformation from waterfall to agile operations. The difficulties that lie within that transformation are, well, many. Some I knew were likely, other companies have suffered the same problems or very similar ones. Some are more context specific. That’s all cool. Stuff happens. It’s not so much the stuff but how you deal with it and move on.
One of the ways of dealing with the stuff was a request from my Manager to be an agile evangelist. Again, that’s cool. When I had a sniff that we were going to head down the agile path to development nirvana I was full bore in to learning about agile. Getting asked to sing loudly from a hymn book written by a number of people I really respect was no hardship. Hell I was being asked to recruit a choir to sing with me.
This week I had my mid year performance review. No big deal, casual chat, some observations, the usual sort of stuff. Considering the shake up the company has been through recently it was sort of remarkable we even held this ritual. In some ways it was actually one of the better ones I have had across my career. There was some feedback from my Manager, all of which was fair enough. Yes sometimes I jump over the top of people when they are talking (I have physical cues I use to tell myself to shut up but sometimes, well passion overrides manners and cues). I can cop that and I’ll continue to work on it.
The one bit of feedback that struck me the most was “you need to be more pragmatic”. The same guy, only months before had told me to be evangelical. Let me highlight via Dictionary.com (the highlighting is mine):
Seems to me there is a bit of clash if you are asking for a practical zealot. Reminds me of when I trained dogs. Occasionally a client would tell me they wanted a family friendly security dog. You would have tell them to make a choice or get two dogs because you are talking canine behavioral extremes (of course if you are in to dogs that will playfully tear your arm off then let’s talk).
So out if this I also have poor body language and might not always support the latest cause at 110%. I knew this of course, could hardly argue it, but, if you are going to ask for a particular behaviour be sure you know what you have ordered so you’re not surprised when it arrives (and the possible behavioural side effects). I’ve been involved in discussions of late that, quite frankly, shocked me with some the suggestions on how we should change. Much of it pointed to more process and more tick boxes. The agile evangelist was not happy. To be honest, this did lead to a great discussion (especially when I pointed out the variance in terms) and has largely allowed me to think about how to reconcile the situation. It’s also helped lessen an “inner turmoil”. I’ve always been pro company and supporting change. I’m not a company puppet but it makes more sense to try and influence good change than just deny change or flat out oppose it when it is going to happen anyway. But I’ve been in a place that has not been overly useful to me or the company. That stage has now ended. The evangelist has to be put away, for now anyway, and the pragmatist allowed to roam free. The evangelist won’t disappear for good, that’s not the way I operate. A holiday perhaps to recharge and refresh, waiting for the next opportunity. When it does come back it might be just a bit wiser for the experience and more valuable for it.
If anyone has had similar experiences I would really love to hear about them.
Many years ago I was a Business Analyst. I’m not anymore but I still remember the role and how difficult the job can be. I still remember how frustratingly difficult it can be to write good business requirements. I remember how you could spend significant amounts of effort writing those requirements, think them “bullet proof” only to have people shred them (not always for the right reasons). It is frustratingly difficult to write about business level gaps and not barge in to solution description. In my role as a tester I read the business requirements and, more often than I would like, wonder what problem the client is really having, what are we trying to solve. Sometimes I even wonder why the business requirements make relatively simple changes seem complex. This is not a statement about the quality of Business Analysts, we have some very capable, smart people in these roles, it is a statement about the difficulty of the task.
When you commute to work you have a bit of thinking time on your hands. Now I’m not sure if I read something recently or a bunch of recent events just crystallised in my mind, but either way I started thinking about business requirements. Now I should state here that I’m really talking about business requirements in the contexts I have worked. Others may not identify with the following and may feel that business requirements are AOK.
Business requirements are an abstraction of a problem. Business requirements are a statement that:
Business requirements tell us that there is a problem but not specifically what the problem is. Now that may sound strange but the language of business requirements moves the writer away from directly expressing the issue. “The system shall……” nobody has ever verbally stated a business requirement that way since the ark was constructed (and possibly not even then). So we are using, what I think of, as an artificial rather than a natural language. Why? Because we need to make sure that the requirements are specific, not ambiguous, etc, etc. Don’t forget that the books and courses also tell us this is the way to capture them. Does it work? Not well enough I’d say. Client discussions around what a requirement meant, post delivery, are not that uncommon.
So let’s get back to the discussion and gathering process. The client tells us they have a problem, they may not understand exactly what the problem is, especially the full depth of it. The Business Analyst is taking notes, asking questions, forming impressions. Eventually these impressions make it to the specification document. Ever play the game Chinese whispers? You whisper a phrase and pass it down the line of people. By the time it gets to the end of the line it is not the initial message. Business requirements gathering is that game. The BA is documenting their impressions of someones impressions of a problem and then abstracting that to a specific language style. Yep things get a bit iffy.
We gather business requirements while discussing the client problems. As a business analyst am I focused on understanding the problems being described or abstracting these to business requirements? Given that the business requirements are a deliverable of the exercise I’m fairly sure they get in the way of really understanding the problem. I think human nature is to focus on the thing you are directly accountable for, even if that may not be in the best interests of client happiness. Business Analysts I have discussed this with tend to support the theory.
A further complication, a potential proliferation of business requirements. If you can read, understand, and, hold in your head 50 (100, 200, or more) business requirements, you might, just might, get an inkling of the client problem. Most likely not because that kind of human memory allocation lies beyond normal limits (and it’s impacted by the other issues I’ve noted).
I’m proposing an experiment where I work. Let’s try not abstracting away from the business problem. Let’s try actually capturing the problems and describing those in direct terms, natural language if you like. Let’s demonstrate to the client that we actually do understand the problems to be fixed. Let’s work closely with the client. Let’s see if we can move away from the post delivery “but we thought the requirement meant……..” syndrome. When we engage with clients we do so to deliver a meaningful solution to a real problem. Let’s get clients to talk to us about the problems they need solved, no branching in to possible solutions, just the problems (I’ve done this with a client, it works. They do you give you a strange look when you tell them no solution discussion). What does the problem look like using real world data, how does it manifest, how does it impact? Of all those problems which are the ones that need priority attention? When we really understand what needs to be solved we can construct holistic, high quality solutions that really do delight clients. When we get this level of understanding we are not guessing using abstract requirements statements we are working with descriptions of real problems and we are talking to clients about those problems using language we both understand.
Will the problem statements work better than business requirements? I don’t know (I think they will but I have no detailed history of success in this context). I’d like to think they will as they should focus directly on how we can deliver value. Will our clients accept this a change of practice? I don’t know. If we can experiment and show value I think they will but no guarantees. Sometimes lack of change seems to keep people happy, even if it is not a great practice. I can’t tell our clients what value is, I can try to help them understand that a particular practice could be beneficial but I can’t force that on them.
I’m really interested in any thoughts people may have on this approach or past experiences.
I like experiments, I like to try and encourage others to experiment with ideas. There is safety in a properly organised experiment. Test out your theory but limit the downside. Allow yourself to get an understanding of why something worked or failed. Slowly tinker with the structure to improve the results. People and teams grow on the back of experiments. Fear of failure is not a reason for not experimenting, it is a reason to start experimenting.
I’ve been a fan of mind maps, on and off, for quite a while. In more recent times I’ve become much more consistent in my use of them. The strong visual representation of ideas really works for me. When I move information from the a flat paragraph to a visually rich representation I get a level of insight that really helps my thinking.
Recently I introduced the idea of using mindmaps to the scrum team I work in. There was a lot of positive interest. I was confident that this would work, the team didn’t have the same background, they, reasonably enough, wanted to see the proposal in action. We agreed we could experiment and ensure that if things didn’t go so well we could recover without too much effort. Accordingly we selected a small project.
We approached this by mapping the epic, decomposing to user stories then finally acceptance criteria. Even for a small project this approach led to some amazing discussion because we could clearly see relationships, unintentional crossovers and potential conflicts or gaps. We actually identified a user story we did not need. If this approach is going to consistently trigger this level of discussion, that alone is ample pay off. The result was a very understandable, useful mindmap that could be used to clearly demonstrate the current project thinking, and understanding, to stakeholders. Should we need to make changes the overhead will be minimal and the impacts easy to see.
At the close of this meeting I decided to continue this work and map test ideas in to the framework. At a high level this showed coverage of the acceptance criteria as well as other wider considerations. I do this anyway as part of me thinking my way through testing a story but it was great to be able to tie it back to the same kind of thinking. It delivered a picture of understanding we had not, as a group, produced before. Should something change between now and when I can start physically testing the code, no big deal, these are high level ideas not low level scripts.
It didn’t stop there. After the meeting one of our team members was so pumped about the process and the results she published the example to the BA and PO Guild lead. I love seeing people buy in to an idea and then start evangelising for it. There was an interest in the Guild – awesome! My team has decided we need to do more of this and we have a few more small projects on the horizon that will be great for this purpose. There is some excitement that we have found a way of communicating that will add efficiency to our process and help us improve the quality we deliver. Already we believe this can translate to bigger gains when we move to larger and more complex projects.
I would like to expand the use of mindmaps well beyond our current use, but for the moment I’ll settle for demonstrating value to the business, that will help build trust (I say business as the mindmaps will not get to clients at this point) . We have generated an amount of interest in a key group that will help keep interest bubbling. I’m hoping that this is the start of a meaningful change. As a team I think we are capable of creating the path. I’m hoping soon that one of the other scrum teams will decide to try this approach as well. That kind of organic growth is exciting.
If anyone would like to add comments about their success or problems in using mindmaps I’d love to hear from you.
I recently started editing some articles for the e-magazine Women Testers. One of the articles I reviewed led to me suggesting the writer should think about adding some discussion on operant conditioning. Since I made that comment it has had me thinking, mostly about the time I have spent training dogs. I’ve worked at two obedience schools, in both instances a Saturday morning job that got me away from the IT world and earned me some pocket money. Working with dogs is great fun and very relaxing. You get so caught up in the now of training any work issues just drift out of focus.
The term dog trainer, at least in my opinion, is a misnomer. I didn’t train dogs, I trained people. I trained people how to teach their dogs specific behaviours. Forty five minutes once a week is not enough to get a dog trained in a skill. That time is spent having the owner work with the dog and the trainer observing, providing feedback and encouragement. This is not a talk and watch role, this is, if you are doing it right, very much about observation and active participation. You try experiments, guided by feedback, to get behaviour improvements. I saw a lot of common ground between testing and dog training (but that might be another blog)
I trained dogs using a clicker (basically just some metal in a plastic cover that when you press it, makes a clicking sound), sometimes a dog would be uncomfortable with the clicker and we would use another means. Rare but something you needed to be aware of.
Let’s start by defining behaviour, at least at a level sufficient for this discussion. I’ve borrowed the following from Psychology Today because it is relatively simple and is pretty equivalent to what I would state using my own words. Behaviour is any:
“Observable activity of an organism; anything an organism does that involves action and/or response to stimulation”
So when we want to build a behaviour we are looking at creating a specific response to stimulation. To do this we utilise, primarily, two approaches:
Classical conditioning – I have borrowed from Simply Psychology which states, “Classical conditioning theory involves learning a new behavior via the process of association”. Think Pavlovs dogs and you get the idea. Only the bell is switched over for the clicker. The clicker is going to allow me to signal two things to the dog, the behaviour is complete and a reward is on the way. It takes a little bit of work to build this association in a dogs mind, but not a lot. Some dogs work it out real quick.
Operant conditioning – The following definition is also from Simply Psychology. “Behavior which is reinforced tends to be repeated (i.e. strengthened); behavior which is not reinforced tends to die out-or be extinguished (i.e. weakened)”. I could go quite deep on operant conditioning but I’m not sure it serves any purpose for this blog. If you want to dig into the history of operant conditioning (and there is some interesting reading to be had) there are plenty of resources available.
So let’s put all this together. I want to teach a dog to drop, without going through the explanation of how to actually teach this behaviour, I’m going to get the dogs attention, get it to perform the behaviour. Once the desired behaviour is performed I’m going to quickly “click” the clicker and reward the dog, most likely, but not always with a doggy snack (more on the “not always” bit later when I talk about motivation). The reward is positive reinforcement. The dog likes food reward and is likely to perform the behaviour again when asked because the outcome is in its best interests. There is now an understanding, an important one, between the dog and the trainer. When that clicker goes off the dog expects a reward. You click at the wrong time that reward must still be paid, the contract must be kept valid.
So where is all this going? Good question, thanks for asking. There are many crossovers between training a dog and working with people. Can I suggest that from the above paragraph setting the right learning environment and immediacy of feedback/reward are simple, yet powerful, crossover lessons. Let me say at this point I am not providing a psychological analysis of how to work with people, just passing on some observations that you might find useful.
Keep it slow – get it right
Training a dog to a new behaviour takes time, it often takes a level of patience, it definitely requires keen observation. If your dog doesn’t know how to sit you wont achieve reliable sitting unless you start by guiding (to use the proper term “luring”) the dog. Once the dog gets some idea of what is required we will progressively link a name (“sit”) to the behaviour. When the behaviour is achieved the clicker is used so the dog knows it has done what we want and a reward is on the way. The ciulmination of these steps is our ability to utter a word and have the dog do as asked. What we will not do along the way is attempt to force the dog into compliance, yell at the dog or otherwise behave in manner that will otherwise have a negative impact. The dog will make mistakes, the trainer will make mistakes. Trainers click at the wrong time often, especially when learning how to use this clicker. So what? A click at the wrong time will not invalidate the work you are doing with your dog (sometimes owners require quite a bit of reassurance before they get comfortable with this).
The lesson at work for me is quite simple. When training someone in a new skill, or explaining a new concept, take things slowly. Allow questions, create safe learning environment, allow mistakes. Mistakes are fine, they’re not fatal. Remember Thomas Edison and “I have not failed. I’ve just found 10,000 ways that won’t work.” I have some wonderful experiences where I’ve trained people on a task, they have got stuck and come back to clarify. When I sit down with them and look at where they are at they have taken an unexpected turn and unintentionally found a better way or helped solve another problem I had. I’m now a big fan of the idea that you “show your colleague the path but let them find their own way along it”. Just for consistency in this story, yes I’ve also used this approach in advanced behaviour dog classes – here’s what we want, how do we get there? I learnt things from my clients whenever I did this.
I do things because it is in my best interest
Whether dogs can actually process that thought, I don’t know. I have my doubts, can’t rule it out, but I do know they will behave in ways that derive a great outcome for them. Dogs crave attention, in my opinion, this is one aspect of their behavior that aligns quite strongly with human behaviour. Both species are, essentially, pack animals. We like being in groups, we enjoy getting some level of attention. When a dog learns a new behaviour we reward it often (continuous reinforcement), as that behaviour becomes more and more reliable the rewarding becomes more sporadic. There are a few reasons for this but ones of the things this reward pattern achieves is improved performances of the behaviour. I borrowed the following from Dog Star Daily “Variable duration reinforcement is really good at getting dogs to perform for increasing lengths of time. Since the reward-time is unpredictable, the dog’s behavior does not drop off immediately after each reward because the next one could be just one second later.” The rewarding, while now sporadic, does not stop completely (note: the article actually talks about phasing out rewards, I removed this as I don’t believe this is good practice). To do so risks the dog stopping the behaviour. This is called behaviour extinction. The dog is simply saying “nothing in this for me, why should I do this for you”? Before we move forward let’s consider “why do I train my dog to perform a behaviour”. Dogs are trained in behaviours because it delivers benefits to their owners. The dog is a better companion because of the obedience, you have better control over the dog. All round dog ownership becomes a much better experience.
Let’s spin this in to the office space. How many times have you taught someone a new skill or had one taught to you, and, upon applying it the first few times, received great positive feedback that then just stops? How does that make you feel? From full on praise to no acknowledgement at all. Does that take some of the gloss off the shine it had when you learnt the skill? Is the task still worth performing? Being a professional the answer to that question is probably “yes, but…”. Very few tasks are handed over to people in perfect shape. A new set of eyes will often find new ways of doing things that save time, produce better outcomes or both. You need people awake and alert for this, innovation requires motivation. Spend time noticing what people do, especially when they are doing things that support you and make your work life easier and more productive. Rewards don’t need to be big, they just need to be sincere.
My dog is stupid, it doesn’t understand me or listen
As a dog trainer I never got in to the “dog analysis unit”. These are people that work at dog schools that have spent working out what troubles a dog and how to work toward a “peaceful dog” outcome. These people work with some dogs that have very nasty habits and bad temperaments. I’m not going to talk about these kinds of dogs and issues here.
My general opinion, dogs aren’t stupid. Another general opinion, people aren’t stupid. In both cases some pick up skills faster than others but the inability to pick up a skill doesn’t make you inherently stupid. When a person would come to dog school and complain about their dog being stupid, unreasonably stubborn or non responsive I’d borrow the dog for a few minutes. Generally this would be a short walk with dog on leash. In nearly every case the dog was fine, attentive and co-operative. Why the difference? Well it generally came down to a couple of factors. I’d worked with dogs, I had learnt to do several things. Speak directly without being harsh (a direct but neutral tone) and use good body language. You don’t ask dogs to “sit” you tell them, but in a nice way. In doggy terms I was showing leadership, I was providing direction. In the absence of direction the dog will decide it is the leader (and this can create some significant behavioural issues). I like to think of this interaction as being me crossing in to the dogs communication style. Earning some canine respect.
I don’t agree with everything every one of work mates, colleagues and friends say. It’s my right to have a different opinion. I respect people for having an opinion, I hope they give me the same consideration in return. Some people are hard to work with but that is no reason for not working with them or respecting their views. I’ve learnt the importance of this, and it would be fair to say, the hard way. I regularly see people making the same errors I have made. You really need to understand the people you deal with, how they best communicate, their communication, and even learning, style. Radiate respect, use good body language, use language appropriate to the people you are talking to. Your inability to move people across to your point of view does not make them stupid, unresponsive to your needs or stubborn. It makes them different, they don’t instantly see the point or benefit you are promoting. Understand the differences. Take a metaphorical walk and see what you can learn. Learn when you should lead to ensure the required direction is provided.
But everybody loves this…….
Are you sure? Every dog loves food, right? Well that’s close but it isn’t always the case. Some dogs I’ve met were so uninterested in food I would wonder if they were actually canine, the behaviour so far removed from the dogs I had owned. Why is this important? Good question. As mentioned earlier a dog does things because it is in their best interests. Another way of expressing this “what motivates your dog”? I use to have the occasional class member ask me what motivated their dog. Given they lived with the dog, and I’d only met it fifteen minutes before, this always struck me as an interesting question and perhaps a glimpse in to the dog/owner relationship. Motivation can be so variable. I’ve trained dogs that found food motivating but only if it was hot dogs or a particular type of ham or a specific type of dog treat. One specialised in a particular cheddar (right down to the brand – by the way, bit of trivia, most dogs love cheese). But then I had a dog whose attention we could not hold because every time a bird flew over, it’s motivation, in all the wrong ways for training, went through the roof. It was a breed of bird dog with a very strong genetic behavioural disposition. We resigned to never being able to break that motivator but we did find a toy that did a good job of getting the dogs mind on task. I had another dog that had no interest in anything other than a tennis ball. Quite simple really, “Fido do as I ask then you get to chase the ball and we will do it all again”. Amazingly effective when you learn what works.
Ok, let’s leave the dog park behind and hop back in to the office. I mentioned earlier that rewards don’t need to be big, they just need to be sincere. That holds but they also need to be targeted. When you have people working under your management, those people are clients. When you work with people, all contributing to a common outcome, those people are stakeholders of yours (well at least that is the way I like to think of it). Think about your external clients. Would you use the same motivators for each of them? I suspect that is unlikely. You would think about what each relationship means, what you know about the client, what they prize. Rolling up to a client meeting with a big chocolate cake and lots of useful information might be great at one meeting. Take that cake to your next meeting where the staff have signed up to a corporate fitness and diet challenge and the motivator may be viewed in an entirely different light. The bottom line here is understand what works for the people you work with. A pat on the back, a “well done” might work for some and not for others. It might work for some but not all the time because they have heard it so much it no longer has a motivating effect. Again keep it simple, keep it regular, keep it sincere. When something really special happens then up the ante and make a big deal, help people understand that hard work leading to great results has real value. For all of that, the one thing that possibly motivates me most, is when someone says to me, as I’m packing up to go home, “Thanks for today, great job, you’ve really helped”. In my current scrum team there are several team members, especially the ScrumMaster, who say this, or something similar, every evening. Why would you not want to return the next day?
As I’ve been writing I’ve had other items pop in to my head that could just as easily be part of this article. Maybe another blog, another time. Maybe some encouragement to extend the analysis. For the time being, enough said.
Thanks for dropping by.
Ok, now it’s time to finish the story. To those that visited and read the first part of this article, thank you. I’ve been surprised and also very happy at the visits this site has had.
Sit down, strap in, hang on, the road to Agile can be a bumpy one. Here we go………
“And it’s whispered that soon, if we all call the tune,
Then the piper will lead us to reason.”
It is really important for teams to remember that a user story is a reminder to have a conversation about the value to be delivered. I’ve found that quite often stories simply become too big, too much information. It becomes a planning up front exercise and almost obliterates the importance of conversation. I like the idea that “if you can’t fit the detail on a card, get a smaller card”, the spirit of this idea is spot on. I’ve also seen that user stories get created large and stay that way. The notion of breaking user stories in to small slices of value is not an easy one to get your head around when you have just come in from the “waterfall winter” into the “agile spring”. The team I am currently working in was doing this when I joined them. Large user stories with many, many tasks (so, so, so many…..by the way tracking these suckers is time consuming and delivers no value to the client). The story points were allocated at the task level. The points were recognised when a task passed to done even though the task might not have delivered any client value. I see this as a relative of waterfall. We now work on small stories and keep task cards to the bare minimum. We recognise story points only when the user story crosses in to Done. We build user stories using the INVEST heuristic. Everyone has a laminated copy of this on their desk, there is a large A3 poster of it in our work area and also in the meeting room we generally use when producing user stories.
Another issue I have noticed is that acceptance criteria, for whatever reason, are often not defined, not seen as important. I’ve spent considerable time on the development floor talking to people about why acceptance criteria are important. My current team now has Definition of Ready requirement – user acceptance criteria defined. I didn’t champion that change, one of my team mates did (happiness – someone was listening).
Sprint planning can be a tricky beast. People start keen, feel familiar with the process quite quickly and start to “auto-pilot” their way through the session. Keep sessions short but punctuate the session with breaks every 50 minutes. People will focus better if they know it is not a continuous 3 hour session. I really favor keeping people on their toes in these meetings. I ask people for opinions on cards when they may not be expecting to be involved. It’s a really important period for people to be thinking about what is coming up for them to work on. Do we have unknowns, uncertainties, let’s capture them. If you know something the rest of the team doesn’t, reveal it so everyone is aware. The power of “group think” is important in this meeting. Think about the size of the story, is it testable? If it is a technical card keep the developers honest. I’ve seen plenty of attempts to gold plate a solution why beyond the value proposition required for the project. Be alert and challenge when you think it is required.
When I first started in an agile team we estimated using story points, relative sizing. Management could not get their head around this. To be fair, that’s not surprising, they spent little time trying to understand it (not that it takes a lot of effort, it’s no Mensa puzzle). After a period of time they discovered that each of our scrum teams had a different idea of what 1, 3, 5 user points looked like. Kinda blew their minds, their response kinda blew ours. Mathematics is a magical thing, you can do things when you manipulate numbers. In this instance a whiz kid with a spreadsheet figured out that a user story point represented half a days work (did you know every time you equate a non standard item such as a story point to a defined value such as half a day, an agile fairy loses its wings – makes me sad). So from then on people swapped story points with days as if they were the same thing (wait a minute, small correction, a story point is bigger as one of those represents only half a day of effort). Can I just say, and this is just my humble opinion, choose days if you want, choose story points (relative sizing) if you want but DO NOT use both as if they are an interchangeable currency. If I may borrow from AC/DC, it is the “highway to hell”.
Stand by folks, a bit of controversy, I HATE stretch goals. There you go, I said it, I’m an agile heretic, or am I? I’m quite binary on this. If the story is of value and can fit in the sprint, it goes into the sprint backlog. If it can’t fit in the sprint backlog, move something of lower value out. If there is nothing of lower value leave it in the backlog. If, and only if, we start getting through stories faster than planned, then bring the story in. The minute you create stretch goals people want to meet that goal. They start working a little faster maybe, they cut a corner maybe, all for the thrill of getting that elusive stretch target and gaining “awesome” status. How about we just focus on producing sustainable quality, seems like a better target to me.
I’m also a little wary on team velocity, don’t just accept it, understand how or why it is a particular value. I worked in a team where one team member in particular did a stack of out of hours work (he just loved the project with a passion). This is great but it artificially blew our velocity through the roof and management jumped on what that could mean. It is also not a sustainable practice. The team had to request less of this “passion” work so we could ensure sustainability. As counter intuitive as that sounds we had someone sprinting when we needed him to be good for a marathon. Use it but don’t abuse it. When the intense bursts are required be ready for it, otherwise aim for a steady pace that delivers value to clients.
“And a new day will dawn for those who stand long,
And the forests will echo with laughter.”
This is the bit about scrum that does my head in. Not because it is hard to understand the value, not because it is hard to understand why it is a prescribed ceremony, not because we do it but because the delivery of value seems to be exceedingly difficult. I actually do not know where to start. OK how about people showing up unprepared to take part or not caring because “other people will put stuff up that I would have put up” (and yes this was actually said). In part 1 of this article I mentioned not everybody is up for the change (people love change they just don’t like changing), I think you see it manifest here. The team ethos, it’s agility (or lack of both), gets laid open in this meeting, cost for no value. make a habit of noting things (good, bad, otherwise) as they happen so you don’t forget. But don’t wait for retro to discuss something that should be discussed now. Instead discuss it now and report the outcome in the “good” column.
So let’s say we have a good retro session, we identify some actions for follow up. Where to from here? My experience is that they (maybe) get put on an action board, no specific champions and at the next meeting get explained away as having been actioned or no longer relevant. Awesome, all inspecting, no adapting (was that another agile fairy plummeting that I just heard?). Let’s ramp this up a notch. We identify actions that will improve the team, we create story cards, we add them to the sprint, we’re gonna do stuff, umm no we’re not. Why because the Product Owner seems to have power to force other stories in to the sprint backlog as higher priority. Raise this to management, who want to see improvement in the teams. Response, not word for word here, but in summary “improve on your own time” (that was an agile fairy expiring, I’m sure I heard a faint scream). Improving on company time costs money. The ability for it to build better teams and all the good things that come with that are somehow less important.
To round out this part of the discussion, there is, apparently, only one way to run a retrospective. I was quite surprised by this, still am. It seems that when a company is contracted in to help you transform to agile the retrospective format they show you IS the definitively best way to run one. Now I’m not overly clever but you do get the odd thought that there might be more than one way to skin this cat. As ground breaking as this may seem, when you look on the web, grab a testing magazine, read a book or two it turns out that there are a lot of ways of running retrospectives and, this blew my mind, it doesn’t have to be run by the Scrummaster (note: my sarcasm meter topped out on that last remark, for health reasons I’ll refrain from further sarcasm for a little while). Can I just suggest the occasional change up, doing something a bit different, something that might be really relevant in the context of the sprint, is a good thing.
Quality and Value
“If there’s a bustle in your hedgerow, don’t be alarmed now,
It’s just a spring clean for the May queen.
Yes, there are two paths you can go by, but in the long run
There’s still time to change the road you’re on.”
“There’s still time to change the road you’re on”, were Led Zepplin singing about agile, scrum and client showcases? Although a bustle in your hedgerow is probably not the trigger for a showcase (can anyone that knows what that line means drop me a message – sorry off task but I really need an explanation). So lets talk about definition of done (DoD) and showcases.
What can I say about DoD? I guess the first thing is make sure the team has one. It’s probably assumed this will happen. You might assume the tester/QA analyst on the team would drive this. You might assume that the team being so focused on sustainable quality would put this high on their list of things to do. Don’t make that assumption, it doesn’t hold. A recent comment from a colleague was quite interesting, “it’s just a checklist”. OK, can’t argue with that. Maybe think about what that list represents. Every time an airline pilot takes a flight it is checklists from gate to gate. Doesn’t matter how many hours flown, those checklists must be run. It’s not a lack of professionalism driving this, in fact it is the opposite. Professionalism drives the airlines to ensure the delivery of consistent quality, checklists help this. I’m not a nervous flyer, I love flying but I do like the idea that the guys up the front are going through checklist that, for example, makes sure those wheels are down and locked when we land. DoD, in my mind, represents the same thought process. What do we need to do to ensure each story is delivered in a state that delivers the highest value? Right, let’s capture those things and check them off as we go. Let’s use consistent inspection to make sure we are checking for the right things. Also be aware of teams that apply DoD at the very end to check if the card should be allowed to cross to done. Get them in the habit of applying DoD across all phases of the story so the step across to Done is an easy one. Get your DoD right, apply it rigorously and consistently and you have a pretty solid piece of your governance layer in your control.
In the team I’m currently working with we have out DoD printed large size on A3 and up on a wall for all to see. I have laminated A4 size copies sitting on all team members desks. As we think of things to add or remove from our DoD sticky notes get added to the A3 copy. These then get discussed by the team, the DoD gets redrafted a required and new copies re-issued. Seems to work really well.
Showcases fascinate me. The idea is a really strong one, I’m seeing too many people treat it as an optional item rather than a ceremony with real power. Show your stakeholders what you have built during the sprint, get feedback, use this to plan the next sprint, make changes to the product backlog, etc, etc. What happens if your client isn’t really interested in attending (remember the company decided to go Agile and use scrum, the clients didn’t request this change)? What happens if you are running 2 week sprints but your company has decided to hold internal showcases every 4 weeks? The internal showcases are great for getting the development floor together and demonstrating product changes but for generating meaningful feedback, useless. My answer to this is to run showcases, just for the team, at the end of every sprint. Why? My thinking is that across a sprint you look at bits of software, you focus on the stories you are involved with. You have knowledge of what the sprint is achieving but you don’t see the bits at a more holistic level. Neither does the Product Owner. This gives the team a chance to look at changes from a different level, perhaps ask new questions about what is being done, bring new insights about possible new value or changes that would add greater flexibility, better user experience, new conversations we should have with the client. Use this session to drive thinking around what the highest values in the product backlog are. Have our views on this changed now we have seen the software operating beyond the individual story level?
Testers – Who Are They?
“And as we wind on down the road
Our shadows taller than our soul.
There walks a lady we all know
Who shines white light and wants to show
How everything still turns to gold.”
Easy answer right? These are the people that harass the developers and tell the story writers they are using ambiguous language and writing stories that cannot be tested. They shout joyously when finding a bug and……… stop right there. If you are nodding your head in agreement either shame on you, or, you have my sympathies because you have some significant dysfunction in your team.
When I first ventured in to scrum I had a big question that I could not get answered. Every time I ask it the agile consultancy would go deaf, pretend not to hear the question. The question – what is agile testing? I decided I could probably find out the answer myself. Turns out there is no agile testing, just testing in agile. Bring your test skills from waterfall, just be prepared to use them in different places and don’t hold back testing to the end of the story, test from inception to Done. Be willing to learn new and apply new test skills. Your ISTQB Foundation Tester is not the be all and end all. Get busy get learning. If you don’t understand the basics of exploratory testing, get cracking and start learning it. Even more importantly start applying it. Get comfortable with the idea of minimising test scripts while still meeting your obligations within the context of the engagement. Learn to understand the context of the engagement so you don’t use inappropriate test techniques (yes this is not an agile specific thing but doing the same thing over and over without thinking about its relevance to the context, drives me crazy. Good and great testers do not do this). Regardless of how you document your testing to be executed keep it to the last possible responsible moment, maximise the power of change without needlessly increasing waste. Think about whether a bug needs to be logged. Can it be resolved without being logged? Can we do this and ensure that the problem is fixed and not forgotten? If yes then get the team together and make sure the team agrees a procedure to achieve this. There might be times when you do need to log a bug. Recognise when this is and make sure the bug gets logged. Perhaps your context demands that every bug get logged, in such cases, ignore my previous bit on minimising bug logging.
“And if you listen very hard
The tune will come to you at last.
When all are one and one is all
To be a rock and not to roll.”
Everyone on a scrum team is a tester. Sure it might not be their specialty but everyone can test. Some might need more guidance than others, it might take the “non specialist testers” longer to complete the testing but they can test and they can test well. I’m lucky I work in a team where everyone makes themselves available to help with testing when it starts to get a bit busy in the test arena. Not all teams do this (I mentioned silos within a team earlier). I wont accept testing being completed at a lower standard but I will accept that more coaching and teaching my be required. It might mean I need to work a little longer some days to support my own work and get others to understand basic requirements. What I get in return though are team mates that are getting more engaged in ownership of value delivery and they are upskilling. They are not going to become incredibly skilled testers any time soon but they will be useful testers soon enough. That is a massive win for the team and moves us another step closer to improved sustainable quality at higher sustainable efficiency levels. Do not underestimate the motivational effects cross training has within a team. It is a real team builder.
“And she’s buying a stairway to heaven.”
“There’s a lady who’s sure all that glitters is gold
And she’s buying a stairway to heaven”
If you read my first article you will have some background to this article (along with a number of side musings). My last post promised to delve a little more deeply into my experiences and observations around transforming from waterfall to Agile. This is that article.
One of the things that has crossed my mind more than once is, if agile transformation is the answer, what was the question? I’ve asked a number of people this and I’m not sure I’ve ever got a convincing answer. I’ve got a lot of “dunno”. I ask this question, “what problem are we solving”, quite a bit when someone presents a solution I’ve not been involved in. It’s not my invention, I’m not the first to use it, but seriously, it creates some puzzled looks at times. Those are the times where you realise someone has probably developed a solution based on their needs, possibly solving something that is not a problem for anyone else, possibly creating new roadblocks for other people. As I write this the phrase “best practice” pops in to my head. Left field sarcasm?
My first observation, if you don’t understand the problems presented by your current development approach then you can’t know if changing will help. Understand the questions that Agile must answer before engaging in the first step of transformation. Spend some time finding out if Agile is even capable of giving the required answers.
I remember in a meeting, early in the transformation, mentioning that it was highly likely not everybody was up for the transformation. How did I know this? Reading up on others that had gone through the transformation, I’d been involved in other companies that had undergone significant change (although not involving agile), I’ve spent some time studying people – as part of my undergraduate learning as a teacher (a long time ago) and some other courses since, and of course just getting to understand the people I worked with. I distinctly remember an uncomfortable feeling coming over the meeting, some muttering, a weak attempt to acknowledge I’d said something, and then, moving on.
Observation number 2. There can be (more than likely will be) significant levels of resistance and denial. This can be a damaging force. The transformation is challenging, people actively resisting just encourage others to stick with old habits rather than developing new ones. Be prepared and get people prepared early. Make it as gentle and gradual as you can. Stage the rollout so you can embed lessons learned and use success stories to generate enthusiasm about the change. You won’t kill all resistance but you can manage (encourage) it down.
“There’s a sign on the wall but she wants to be sure
‘Cause you know sometimes words have two meanings”.
Tremendous opportunities will be presented. I expect that this will be true regardless of the level of agile coaching your company invests in. Commit to learning about agile, scrum, testing in general (if you are not already investing in this). Upscale your own education. Just doing this will place you above many others who will be part of the journey but only as a passenger. You will create opportunities for yourself, don’t waste them.
Not everyone is going to be OK with the transformation or even with the notion of having to change to agile. Learn to live with this. Bring them along as much as you can, use all their strengths. If they don’t want to fully participate in the agile ceremonies, don’t force it. Accept what they give, over time, with some successes on the board, they may slowly change. Success is a powerful force. There might also be a bit of “background politics” noise. Ignore this, focus on your team and yourself. Focus on what you can control.
It’s All In Your Mindset –
“Ooh, it makes me wonder,
Ooh, it really makes me wonder”
Having people sitting in the same location does not make them a team. Calling the team agile does not make them so. It’s not difficult to put people together in a scrum team and have them operate in silos. I’ve seen it happen. When people lack direction, are confused by the changes, feel stress because of change, they go back to what is comfortable, what they knew before. You need to ensure there is support for the team, people who can help the team find direction and start using agile practices. This doesn’t have to be an external coach, it can be someone with good previous exposure to, experience in, (in this case) scrum.
Many people who have worked in waterfall have had some real horrible experiences with change. The churn and overload requirements changes can create can border on overwhelming. There is a mindset change required here. Change is a good thing, welcome it. The teams need to realise that change is, or should be, far more controllable within an agile setting and it helps to prevent spending lots of effort on developing something that does not solve the clients problem . Learn to understand, as a team, what is valuable to the client and what is the most valuable thing you can do to help deliver that value.
“Team think” is an important part of the transition. Give people a complex problem and empower (expect) them to find solutions. They are not my words but they resonate with importance. This is such a different approach to the usual waterfall method of development. I’ve been in a number of situations where, as a team, a problem has been solved quickly and produced a high value solution that was the result of using all the experience and abilities in the team. A team is comprised of capable people with different skill sets, different strengths and weaknesses. This is powerful stuff, use it. Personally I’m a fan of the “3 Amigos” approach and encourage this in any team I work in.
I think it is important for people to understand that a person in a silo isn’t the point of failure, finger pointing has no place (it didn’t in a waterfall environment either). If a project fails, the team fails,. not a person in the team but the team. Everyone in the team must own the project, own the decision making, own the commitment to quality. I’m tired of being told “if everyone owns it no one owns it”. That’s garbage and old world thinking. If everyone owns it, is accountable for it, then everyone owns it. If that is not happening then work out why and address (inspect and adapt).
“And it’s whispered that soon, if we all call the tune,
Then the piper will lead us to reason.
And a new day will dawn for those who stand long,
And the forests will echo with laughter.”
I had intended to cover my thoughts on transformation in a single article, but, I’m not convinced that is a value proposition for my stakeholders. I’m not a fan of massively long articles so I want to avoid doing the same myself (although massively long is soooo context based I might not even be close to that point yet for many). To make things a little easier I’m going to add another article covering other aspects such as agile ceremonies and other processes.
Part of my usual lunch time routine at work is to get myself some distance from my pc. I’m not a big fan of eating at my desk, and not really leaving work to one side for a small while. Many people underestimate the value of making that break, getting your head out of what business problem troubles you, refreshing, and coming back with a clearer state of mind. This morning, I had a brief, but interesting, discussion with two of my team mates. I thought it interesting enough to share.
Some background. We are delivering an enhancement to several of our clients. The project has been interesting for me for a number of reasons. This is the first project I have spent with this team. The first sprint was kicking off as I moved over from the team I had been working with. At that point my new team was agile only by company description, it’s actually the reason I was asked to join the team. We are a much improved team some 10 weeks later. Still a way to go but good signs that we are travelling in the right direction.
During early testing of the enhancement both the team BA and myself, almost at the same time, noticed that a piece of legacy functionality, when used in context of the new function, was not really correct. The initial response “The clients know this and are OK with it”. We thought that there was value in making the change, the data being reported was not right in some scenarios, but placed it low on the product backlog as we had plenty to do and if the clients weren’t chasing the change then the value proposition wasn’t massively strong (and one could ask why we wanted to add it to the backlog at all). As it turned out, funnily enough, one of clients did want the report changed, we, apparently misunderstood a business requirement. It should have been there all along. At least that added gravitas to the story being in the backlog.
I guess at this point I could talk about how something we thought might be easy, turned out not to be, but then turned out to again seem pretty easy to achieve (all because we were thinking and learning as we went and not committing big design plans up front – another blog some other time). However my intent was to talk about a conversation…….. So, this report can be produced in two ways (probably more if we wanted to be really inventive but that would likely accrue cost well above value). The conversation went something like this:
BA: I think we need to make the changes via “X”. We could do it via “Y” but that would mean we have to retest a lot of stuff.
Me: Do we know for sure there is a lot of risk making the required changes in “Y”? We’ve only just started with “X” so we know the risk is low, and especially so because of the way we retrieve the data”
BA: Haven’t confirmed it, but we have done a lot of testing so changing “Y” becomes risky. A lot of retesting.
Me: If you were the client does the report gives you greatest value when it is part of “X” or part of “Y”?
Me: Yep, I think the same thing. How about we talk to the developer and get an understanding of the risk profile. We should focus on delivering the highest value. We could even raise this with our clients. They might not actually want the report in “X”, although I strongly suspect they will. We can consider the full implication of our choice once we get some more information.
Pretty much end of discussion ( at least any bits I want to put in here).
There are a couple of points that stood out for me in this conversation:
1. even though the highest value proposition was thought to be “Y” it was not assigned “best option” by default
2. perceived, rather than known or analysed, risk was allowed to influence a value choice and move us away from “Y” (preferred) to “X”
How often, at work and outside of work, do we make choices and go for the safer option rather than grabbing an understanding of the risks involved with our preferred option? An option is preferred for a reason, we perceive that it will deliver greater joy, the quality of our experience will be higher. When we go the lesser preferred route we run a real risk of undervaluing potential joy and satisfaction, interactions that will feed into an assessment of quality. My suggestion, remove those assumptions, question them into knowns, get them to a level where we can make informed decisions. Once you have done that select the option that will deliver the highest level of delight.
Well, here we go, my first blog. I swore, some time ago, that I would not be a blogger. I’m not sure if that makes me selfish or not. Happy to read the thoughts of others, learn from them, but then not give something back in return. Weirdly that thought only came to me as I type this. Anyway that’s a bit off the track I intend to go down in this bit of writing. I use LinkedIn. Sometimes I love it, sometimes some of the commentary just drives me nuts. Inevitably I go back for more. Why? Because, at the end of the day I like the majority of the discussion. I have met some really sharp thinkers. They have introduced me to ideas, that I might have eventually stumbled upon, that have helped me improve aspects of how I test, how I think, how I interact and react with people. The same is true of the many people I engage with on Twitter. It is a privilege to have so much global knowledge so accessible. Anyway back to the main theme and fate. A bloke, who was an unknown to me at the time, Rajesh Mathur, dropped an article on LinkedIn. I can’t even member the specifics of the article now. I challenged points in the article, Raj responded (in a very cool way). We had several discussions which led to a chat over coffee. That chance happening (and I almost didn’t challenge his article) triggered the meeting of a man that is now a friend and a hell of a good thinker around matters of testing. When I talk to Raj I get inspired by the chat and his ability to convince me I should extend myself even more. He has a positive energy that just radiates and infects people near him (perhaps it’s just me, maybe I’ll set up something on Survey monkey to find out). This is why I’m now blogging, Raj convinced me to start writing. So I guess this is a transformation of one kind.
I work for a software company that decided to move into Agile development adopting Scrum as the framework. I was fortunate enough to be asked to be part of the pilot team (that was a little over 2 years ago). I knew something of Agile coming in to the changeover but, as it turns out, wouldn’t have hurt to know more. Then again it’s all theory until you are in the heat of battle. For me doing teaches me more than books on their own ever will. Mind you I read like a demented librarian, it’s a habit I can’t break (and don’t want to break). I always considered myself a good fit for Agile/Scrum. I love team work, love problem solving, love the idea of being invited to be part of the solution from start to finish rather than having to gate crash. I have a fair level of disregard for the silo mentality. Waterfall, for sometime now, has seemed like a terrible idea to me. My experiences in waterfall have done little to change my mind on its inherent problems as a development method. I was discussing this, and a bunch more, with Raj over dinner at Nandos. As a result of that discussion I was asked to present on transforming from waterfall to agile at AHPRA. While Raj requested this as “a favour”, I just couldn’t see this as anything other than an opportunity. My first speaking engagement to people other than those I work with. Better still Raj bought me lunch. Does that make me a paid professional speaker? I learnt a few things out of this engagement. I spent the best part of a Saturday wandering in and out of my mindmap and Powerpoint. Creating slides, thinking through my mindmap points, reflecting on the transformation experience to date. It was actually an engaging experience, I’m really glad I took my time.
I really enjoy talking to other people about things I have experienced and learnt. If I can pass on some ideas that will save other people time and energy, or at least open options for them, then awesome, I’m paying back on the vast amount of knowledge others have passed my way. I think I actually enjoy the process of presenting, being a little bit of a smart arse and building some rapport, getting a few laughs helps people relax and engage. I enjoyed the feedback that I did engage people and they thought my presentation interesting and useful. I enjoyed that the people attending were very generous, switched on and asked some very cool questions. I’ll never forget the question ” so a story point equals a day”. It was a valid question, but, it is also something that drives me nuts due to a mandate introduced as part of the agile transformation process at work. I was able to clown it a little, address the question, and everyone had some fun in the process. By my judgement that’s a win/win. I’m going to write about this in more detail in my next blog entry. I was going to do it in this one but I like what I have written and adding the extra information would make this hideously long. So…….
Our transformation was supposed to be slow and considered. Start with a single team of people that were both eager to be part of the process, capable of making the changes and willing to feedback in to the process to help other teams transform. A consultancy was engaged. I didn’t have a lot of contact with them, can’t say they had any impact on my development. Others tell me they did a good job. Maybe the idea of talking to a tester terrified them. I know I asked plenty of questions that were never answered, those promised follow ups never delivered. The funny thing is, knowing what I know now, there was a simple answer to many of my questions. Someone just had to point out that there is no agile testing, just testing in agile. Silver lining though folks because frustration led me to hitting the books, articles and on line forums like never before. I learnt stuff that the consultancy would never have led me to. I re-established a thirst for knowledge that had lay dormant for a little too long. I found writers who had been through this and more for years and were sharing valuable information. I got exposure to ideas that lie outside the mainstream “cookie cutter” mentality. What doesn’t kill you makes you stronger (I guess). People say that when opportunity knocks….., don’t wait to be asked or told, just do……, make your own opportunity. I’m glad I did. I’ve become so much more empowered, enlightened and I know more about how to solve meaningful problems efficiently. Don’t get me wrong, I’m nowhere near the end of the journey, I’ve got plenty of roads to travel. If learning teaches you one thing it is that there is so much more to learn.
Back to the transformation. My manager (at the time) advised me 6 months in that the transformation had been “signed off” as complete (that was the view of his manager). All people had been assigned to agile teams (including those in our overseas office that work with us). Lessons learned from our first team, how did we distribute that? We didn’t. Apart from the team I was working in the others were pretty much waterfall using some scrum ceremonies. At least this problem has been recognised and we are trying to deal with it. I was lucky enough to be asked to move into one of the scrum teams and help them shift to agile practices. This has been an awesome experience. The team was highly dysfunctional when I first moved in, they had problems, big ones. Eight weeks later the feedback from the team is very encouraging. The feedback from outside the team is encouraging. The team is transforming. I’m stoked to have influenced change. I’m really pumped that the people in the team took up the challenge. It’s been hard work, breaking old habits, but watching new and better ones form is a great motivator. I’ve learned heaps along the way.
My next blog, I promise, will be my thoughts and observations on transforming from waterfall to agile. At least the background has been set out. Really hope you’ll come back and check out what I have to say.