Community: Self-organized network of people with common agenda, cause, or interest, who collaborate by sharing ideas, information, and other resources (businessdictionary.com).
Community, hanging out with a group of people that make hanging out an enjoyable experience, something you want to do. It’s more than that though, look at the definition I’ve chosen, the key attributes, self organising, common agenda or cause or interest, collaboration. It occurs to me as I write this that community is a good description of an agile team (honestly, that is a side thought, not why I started this blog). When I read these attributes it reinforces to me why many people like to be part of a community, to feel a sense of belonging to a group in which they have common goals or interests. Working together to achieve great outcomes is a good feeling. It is a give and take activity and that’s one of the things that, in my opinion, makes community special.
The Test community, in my mind, is a special one. It is full of diverse people, diverse experiences and attitudes and the majority of them are in to sharing and caring. I think most testers see themselves are being on the periphery of software development. Not really understood by many outside their testing peers.I think the Test community is quite special in the way it helps others, it’s not like any other community I have been a part of. You can connect quickly with people in the Test community and they share experiences openly and honestly.
Seek true positive energy, a place where you can help build the community in a caring and authentic way. Spend time finding those testers that will support you, you won’t need to give them anything because their reward is an enormous feeling of satisfaction through helping someone solve a problem or improve the way they do something. Making a connection for no other reason than being a decent, caring human being, for most, is a genuinely satisfying reward.
In closing I want to send a big thank you to those in the test community that have provided me with great support over the journey. Of late there are too many to mention but a few really stand out. Lee Hawkins, a truly great bloke, a great thinker, a brilliant friend and integrity beyond question. Michele Cross who has been a great friend and has listened to a few rants (she does seem to like a rant). Michele is genuinely funny and always at just the right moments. Jyothi Rangaiah, editor of Women Testers who gave me an opportunity to become a reviewer and has provided incredible support, positive feedback and the opportunity to engage with the test community in a very satisfying way.
If you’re reading this, and you’re a tester and you don’t identify with the test community, make a move to join it in some way. Twitter, LinkedIn, test meetups, join AST and involve yourself in their offerings, whatever you might select, just get into the community and talking. You wont regret the investment.
The Ministry of Testing recently tweeted a list of words that make testers feel “icky” and those that make testers feel “good”. I have inserted the list below.
The list is crowd sourced, provided by testers who responded to a request to provide words that they felt belonged in each category. It is undeniably a good thing to reach out to a community and ask for input. In this case words, and I would hazard a guess, words that resonate emotionally with those that provided them. It is hard to think that there is an absence of emotion in the selection of words. The MoT introduction includes the following:
I’m unclear how gathering a group of words, especially those that highlight “things that make them feel icky or bad” helps address an image problem. Image problem itself is a likely minefield of emotion and a different problem to things that make you feel good or bad. I’m somewhat surprised to see a list that appears to have a similar volume of “good and bad”. I do wonder if this really reflects the actual responses.
Arguably we get an interesting snapshot from this exercise, but, at the end of the day, it is almost devoid of meaning. Where is the context? I mean I can look at this list and see a list of words that testers appear to favour and those they don’t, but how does that help me improve things? I genuinely struggle to understand, as an example selection, why
are on the icky list. As a colleague pointed out to me, offshoring on the icky list is just plain offensive to a of part of her team (they are testers in the Philippines, what the hell did they do to be labelled icky?).
Likewise with the words on the “good” list. Why are these words inherently good? They may make a tester feel good but the goodness is in their use in a context where they are useful and the tester knows how to be effective with the choice. Mobbing or BDD might make you feel good but are they good choices in the context of an engagement? I find it interesting that:
find their way on to the good list. When I think of fast I immediately think of testers that feel good if they are just “pumping through the work”. That is an anti-pattern in my mind if you want good outcomes. Same with complexity. Do testers really feel good about complexity? It would make more sense to me if simplicity was on the list. Without context I’m just guessing.
As it stands the list is just words. If we want to make this a platform for change then lets generate understanding of those words. Lets get the community talking about why words are “icky” and why others are good. Words alone do not improve practices. People with a common understanding, working as a group with common cause, improve practices. This might just be an opportunity to open some excellent dialogue that generates further improvement. The challenge is ours and yours.
Welcome to my blog. This time I’m not writing about testing, management or problems with estimates. This blog is dedicated to something much more real, something much more relevant than our “9 to 5” lives. You see, in the early hours of Monday 29th February, my Father-in-Law, Giuseppe (Joe) Marinelli, passed away. He’d been sick for a long time. Various ailments that, brick by brick, constructed a wall he could no longer grapple his way over. It started with a diagnosis of diabetes. Eventually he lost a leg, amputated at the knee due to gangrene, courtesy of diabetes. You’d think that just might be enough for one lifetime, especially for man that had worked hard and tirelessly for most of his life. Retirement should bring you something better, right? Nature doesn’t play by right and wrong, fair and unfair, it simply rolls on handing out whatever cards are in your deck. Sometimes, if luck is on your side, medical science, natures own change of mind or God (should you choose to believe) gives you the opportunity to hand back a few of the cards and ask for a better hand. Joe didn’t have that luxury, he was out of luck. It’s hard to reconcile in some ways. As a practising Catholic with firm beliefs he should have had a vast cast of Saints and the big Guy himself helping him out. Perhaps it’s easier to reconcile if you hold faith close to your inner most beliefs. While Joe was getting on with walking on a prosthetic limb he was diagnosed with dementia. He fought both dementia and diabetes for while at home with his wife Giuseppina (Josie). Then the going simply got too tough, the cliffs to steep to climb. The last six years of his life being spent in a nursing home where he could receive the dedicated, around the clock care he required.
I could simply farewell Joe at this point but if you’ve read this far he needs to become more than a man racked by relentless diseases. He was a powerful man. To be honest, when I first met him, and for a while afterwards, he could be quite intimidating. Not sure he meant to be, but he was. Like all of us, he was not black and white, but a mixture of infinite shades of grey that blend to produce both lighter and darker elements. A mix of complexity that makes us distinctly human and means that we are not perfect beings.
When you leave your home town of Musellaro, Pescara in Italy in 1955, aged 20, bound for a land called Australia you probably learn a bit of resillience. He travelled with a few family members to help set up for family that would follow later. A year later Josie made the same trip, they were married in 1957 and their first daughter born in 1958. For all but the first few moths of his life Joe lived in the same house in Abbotsford. He and Josie raised 4 children in that house, not big by any means, but comfortable, safe and more than being a house, it was a home.
I can’t consider this story complete without mentioning that Joe was (is) a Holden man. We even made sure that his final ride would be in a General Motors Holden vehicle, the big lion sitting proudly at the front. Joe worked at the GMH plant at Fishermans Bend, Port Melbourne for 40 years. Says a lot about his character. There will never be a bigger or better advertisement for a brand than Joe and Holdens. He loved those cars and the people he worked with (and, as far as I can tell, they loved him as much in return).
In a few days we lay Giuseppe to rest. Forever his legacy will live on. Born in Italy, later becoming a naturalised and immensely proud Australian (he loved Slim Dusty and Holdens – do I really need to say more). His stories, his way of talking, his love of food. I’ll always remember how once he wouldn’t eat dessert unless it was fruit. Then it had to be at room temperature because of sensitive teeth. Somewhere along the way, during his illness, that changed to the point he loved dessert and would chomp through frozen cheesecake. At some point, at the wake, I expect a bunch of Joe’s stories, and stories about Joe, to be told and laughter to follow. These are stories his Grandchildren have heard and ones that his Great Grandchildren will hear.
Joe, you helped produce the young lady that became my wife and my soul mate. We have two kids that you loved unconditionally. You were part of delivering a life I love. Rest in peace, free of pain. You will live on through your family and their memories.
And no, you can’t always get what you want
No, you can’t always get what you want
Well, no, you can’t always get what you want
But if you try sometimes you just might find
You get what you need, baby
Rolling Stones – You Can’t Always Get What You Want
First blog of the year, inspired by conversations and observations. Three stories I’d like to share.
Mr. Play It Safe was afraid to fly
He packed his suitcase and kissed his kids goodbye
He waited his whole damn life to take that flight
And as the plane crashed down he thought
“Well isn’t this nice…”
And isn’t it ironic… don’t you think
Alanis Morissette – Ironic
Client Relationship Manager: “The client isn’t happy. They believe the project doesn’t satisfy their acceptance criteria”
Me: “I don’t remember them sharing acceptance criteria”
CRM: “They are drafting them for a meeting tomorrow”
Me: “You get the irony of this conversation, right?”
How on earth do we get to a point where this conversation can happen? Software vendors don’t work in a vacuum. We build software because clients believe the changes will improve their ability to conduct business, improve their profitability. As much as we know our software, and we know our industry, we don’t intimately know everything about the clients business. We call it the “clients business” because it belongs to them. Do they not have a responsibility to have some input? I truly want to help clients by delivering them high quality software, I don’t want to own or run their business.
Lessons: You cannot underestimate the value of bringing the client on the journey.
Create and maintain a partnership mindset.
But I’m just a soul whose intentions are good
Oh Lord, please don’t let me be misunderstood
The Animals – Don’t let me be misunderstood
The meeting is held, the acceptance criteria delivered. I wasn’t part of the meeting so my involvement was ex posto facto. On reading them I was surprised. The acceptance criteria were in reality a series of very high level, broad statements. We could use these criteria and claim we had met them. Equally we could also mount a case that we had not satisfied them. It was a great reminder that we need to work with our clients, guide them to provide the kind of information we find valuable. There was a surprising delta between what I expected and what I saw. Time wasted by the client. Waste that can be prevented.
Lessons : If you have specific information requirements, be explicit about them. Ensure they are understood. High quality information from the client allows us to more specifically build them high quality software that provides real value
You cannot underestimate the value of bringing the client on the journey.
Create and maintain a partnership mindset.
Is there anybody out there?
Would you hear me if I screamed or if I cried?
I am looking for an answer
Pink Floyd – Is there any body out there
“The client is frustrated with the way we are communicating with them”
I’m actually quoting someone but I’m guessing this is not a one time unique utterance. I’ve heard it before, words might differ, the meaning remains the same.
I have a communication structure that I believe works. It’s not unique, I didn’t create it, you’ll nod acknowledgement as you read it. Communicate in the following order:
face to face, phone call, e-mail.
Face to face – body language, eye contact, immediacy, personal warmth and do not understate that many people will recognise that you have made a special effort. How much better is it to run a white board session in an office while working through problems with your client? Sure, you can run a whiteboard session using an on-line app, but chances are you will experience very little of the dynamics and relationship building you experience when compared to face to face outcomes. I’ve dealt with clients that can really rant and rave over the phone line. Face to face it never happened. Proximity and other dynamics remove this and the meetings are far more productive.
I have found a level of resistance to organising face to face meetings. It’s expected of Consultants and Client Relationship Managers. Beyond that clients are often reticent. It drags people away from their “core activities” (business speak for these people are now generating cost rather than revenue). That’s, in my book, a very limited consideration of the game in progress. My experience tells me that phone calls, while generally shorter in duration than a meeting, will be far greater in number and frequency. They will also feature a reduction in absorption of information. Is this a low cost option – not in my opinion. E-mails, forget them, except when there is no other choice, and then, follow up with higher quality communication. I rarely e-mail colleagues these days, I prefer to walk to a desk and interact with a person.
As a business we need to work with our clients and understand how we most efficiently generate value for them. We need to examine old habits, perhaps ones we have trained them to adopt across years of business.
Software vendors often get blamed for failures. Clients under pressure, wanting a solution but not the one they outlined with their requirements. Vendor clients under pressure from third party business because the software solution is to service them. Humans look to deflect criticism and defend their turf by pointing the finger at “next in the line”. My experience is that significant fault lies on both sides. In itself that is immaterial. The real challenge is for vendor and client to build a strong relationship, move beyond blame and focus on quality.
Lessons: What you say and HOW you say it is important. Not all forms of communication are equal.
You cannot underestimate the value of bringing the client on the journey.
Create and maintain a partnership mindset.
That’s it folks. Thanks for stopping by. Hopefully I’ll see you again soon.
This article was initially going to be something of a rant, it still might go that way. Neil Killick recently tweeted how he loved the honesty of a good rant and there should be more of them (or words to that effect). Inspired I tweeted back that he wouldn’t have to wait long. Sorry Neil, not this time, although the chances now rise of the next blog being rant driven (of course your definition of rant might be fulfilled by this article).
Recently I’ve been musing how things can circle around in unexpected ways. How themes can, and often do circle around until you see that a link has been formed. Multiple pieces of information, each unique in their own way but somehow morphing from linear fact or opinion to smoothly join to another formerly linear slice of wisdom. Eventually they weld to form a nice solid shape that hangs in your consciousness. A shape that increases your knowledge in a useful and meaningful way.
In a previous blog entry I mentioned “Obliquity” by John Kay and it’s main line of thought. I think I might have said that it is a sensational book. If I didn’t then let me say, it is a truly sensational book. If I’ve already said as much, well, it’s worth repeating. I’m currently reading Dan Pink’s book “Drive: The Surprising Truth About What Motivates Us“. This is also an amazing book. I have to force myself to put it down to do other things (like work).
In recent times I’ve had a series of discussions with people (they are all managers) where we largely discussed approaches to people management and motivation. In summary, just to keep this article brief, command and control is alive and well. Much like ISTQB, command and control seems to have a level of acceptance that it should not have. In actual use they have roughly the same relevance and not nearly enough people questioning why or looking for better approaches. That’s a little depressing. Managers want staff that produce sparkling software that makes clients happy, on tight lead times and they want to control them, within an inch of their lives, to that delivery. They want to control the solution creation rather than trust people to do what they were hired to do. They have a management goal, delivery on time, on budget, all agreed features delivered (to add some perspective here, those features were agreed months in advance). The managers are directly attacking a problem that is complex and has multiple flexing parts. This is simply not optimal. That’s not obliquity in action. Obliquity would require us to tackle smaller problems, experiment, build small blocks, ask questions, be flexible and not assume we can charge directly at the final prize. Is anyone else thinking Agile?
Clearly Dan Pink and “Drive” forms another part of the circle. I don’t want to spoil what is a very good book so I’m not going to dive in too deeply. This book spends some time exploring the impacts of extrinsic motivation (carrot and stick) and intrinsic motivation (the joy of just doing something). The notion of intrinsic motivation is, relatively speaking, new. The book asserts intrinsic motivation is not well understood or incorporated by Management in general. My personal experience leads me to agree strongly. This is overwhelmingly true for most managers I’ve dealt with (note I didn’t say all). One of the really interesting things in Drive is the relationship between extrinsic motivation, intrinsic motivation and knowledge work. I’m going to suggest that software development is very much in the knowledge work domain. Consider the following extracts from Drive (the term “third drive” refers to intrinsic motivation)
“Human beings, Deci said, have an “inherent tendency to seek out novelty and challenges, to extend and exercise their capacities, to explore, and to learn.” But this third drive was more fragile than the other two; it needed the right environment to survive. “One who is interested in developing and enhancing intrinsic motivation in children, employees, students, etc., should not concentrate on external-control systems such as monetary rewards.”
Lakhani and Wolf uncovered a range of motives, but they found “that enjoyment-based intrinsic motivation, namely how creative a person feels when working on the project, is the strongest and most pervasive driver.”
“Careful consideration of reward effects reported in 128 experiments lead to the conclusion that tangible rewards tend to have a substantially negative effect on intrinsic motivation,” they determined. “When institutions— families, schools, businesses, and athletic teams, for example— focus on the short-term and opt for controlling people’s behavior,” they do considerable long-term damage.
Both Dan Pink and John Kay are learned men. Their books are heavily supported by credible research, findings of others that are recognised a leaders in their fields. Why the hell is Management not keeping up with the knowledge that is available, why are they not taking in what science has already established? People are entitled to expect better (do Management not expect their people to “continuously improve”?). Is it that hard to trust someone to do the job they were hired to do? Can teams, team members, not be trusted to follow their intrinsic motivation (their third drive) and produce innovative approaches, dynamic, joy making solutions for customers. Just perhaps we need new Managers. Ones that will provide the required freedom that intrinsic motivation requires to work at its best. Perhaps we need Managers that would never ask people to “think outside the box” because that means they already acknowledge that their people are already “in the box”. Perhaps we need Managers that do not tell people to “feel empowered” because just by saying that they acknowledge that the standard status is “you’re not empowered”.
The “almost last part of this circle” comes from a book The Critical Thinking Toolkit: Spark Your Team’s Creativity with 35 Problem Solving Activities by Marlene Caroselli. I plan to run weekly activities with the agile team I belong to. This book has some great activities. A quote that really took my fancy:
Imagination is what takes vision out of its tunnel.
Then I found something that really disturbed me:
“…….a famous longitudinal study of creative potential followed a group of students over a 17-year period. The same test was administered each time to these students. When the students were five years old, 92% of them were found to be “very creative.” By age ten, that figure had dropped to 37%. When the children were fifteen, they were tested again. At this age, the number of children deemed “very creative” had dropped to 12%. Finally, the same students were tested in college. How many were found to be “very creative” at this age? Only 2%!”
We are actively killing creativity at work through bad management and also killing it before our children get out of school. That really is something to think about.
Perhaps it is time we start consistently thinking about “circling” to solutions for complex problems. Give up treating them as 100 meter sprints. In a 100 meter sprint you want to go direct, you want to break the tape first. But that direct approach is fine, this is not a complex problem. Your mission is to run as fast as possible, get there first. However if someone decided to trap that 100 meters with lasers, explosive devices, snipers, and the like, would you still think direct or would you be a little more creative and oblique?
One last thing, a personal experience. Last week I put a critical thinking exercise on the team whiteboard and also a copy in a more central location for others. Within 60 seconds of noting that I’d placed a problem on the board 3 team members went over there and started collaborating on a solution. No prompting, no requirement to do this, no prize on offer, but they did it any way and worked until it was solved. Just chance? I don’t think so. I actually think that it is a very powerful demonstration.
That’s enough from me. Thanks for dropping by. I hope to see you again.
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.