Over the years, there has been a commonly recurring question, "Are we doing Kanban or not?" I've always answered that the answer isn't based in practice adoption but is rather a question of intent. Do you have the intent to pursue evoutionary improvement of service delivery using the Kanban Method? If so then you are doing Kanban and if not then you are not.
This spring I noticed  that the rather clunky name we give to the implementation process for Kanban that we teach in our classes and private workshops has a catchy acronym, STATIK. Just as we hoped, this is turning out to be much "stickier" than the systems thinking approach to introducing Kanban; we find that not only do we refer to it a lot, so do our clients.
We use Slack as a team collaboration tool, and it displays cheering messages on load screens. Such as, “What good shall I do today?” or “You got in, and day just got better”. One such message from Slack inspired me to write this post. The message goes like this: “Remember to get up and stretch once in a while”.
There’s no doubt, that with the bulk of our days spent at our desks, we do need some sort of stretching. It’s hardly that any IT worker, or knowledge worker, will question the need to exercise and to keep fit. Media advertise lifestyles where some sort of physical training is a must. So, if we don’t want to be labelled as “couch potatoes”, or if we lack movement, we naturally want to compensate for that. Many years spent studying, and then working, and sitting all the while, require some sort of compensation. At one point or another, any sedentary worker will want to step on the path of exercising. It seems, what can be wrong about it? Everyone is doing this, and it feels so great to exercise! The devil is in the details, as usual, and I want to outline the trend that I currently observe with some of my colleagues, and which, actually, I observed earlier in my own life. This is not a wellness blog, and this article is not about wellness and keeping fit. It is about keeping ourselves sustainable for doing our work in software development. It might sound as a bummer, but if we put too much of our personal energy into exercising, this will not only be of any good, but it will, in fact, sabotage our productivity.
It’s quite hard nowadays to resist following the lifestyle that media impose. We are told to go jogging, or to ride a bike, or to be a triathlete, or to run a marathon. I’m 100% certain that everyone who will read this article is either doing these activities themselves, or has some friends that do. Now, here’s what the trick is. As I was able to observe, people usually start out with their athletic pursuits after they lack physical movement for many years. It’s as if they are let loose from a leash, and it’s a euphoric experience, to feel yourself moving, exercising, pursuing, being an athlete. Until there comes a time when you realize that this euphoria is not endless, and investing too much effort in exercising backfires, and backfires hard. That was the case with me. In my late 20′s I felt some sort of itching to exercise, and I started out with jogging in a nearby park (on concrete, and jogging on concrete is a knee joints killer, no matter how hype your sports shoes are, but that’s a whole other story). Then, I really got into tennis and passionately devoted myself to mastering this sport. I’m a stubborn and persevering girl, and if you’re serious about doing tennis, you need to keep yourself in good physical shape. So, apart from my tennis practice, several days per week, I did jogging, went to the gym, did some tennis-specific workouts, and I used to have 2 or even 3 training sessions per day (!), and I was doing this in parallel with my day job. Everyone cheered me, because it’s a commonplace belief that it’s such a great thing for knowledge workers to exercise. I managed to maintain this regimen for about 7 years, until at one point of time I realized that I can’t do this anymore. Instead of being a joy, playing tennis — this most beautiful, graceful, smart and elegant sport ever — turned into a dull burdensome chore for me. Besides, my health deteriorated, and this prevented me from doing my best at work. I realized that I need to make a choice, and since I had no intention of becoming a professional athlete, I terminated my tennis practice for an indefinite time. Someone might say, come on, you can just play leisurely, once or twice in a week! The point is that with this fatigue from overexercising that has accumulated over those years, I’m happy and comfortable with this indefinite break. Now I exercise as I swim in lakes (no chlorine for me, thanks), or go on walks, and my favourite way to exercise at the moment is to walk barefoot in a park, on a grass lawn.
Why I’m telling this story? Ironically, I see that some of my colleagues in their late 20′s experience the same curve of being fatally drawn to exercising. They suffer from injuries, but still exercise, as if butterflies drawn to a fire. Everyone lives their own life, and it’s their journey. But I can clearly see, and I can tell from my experience that overdoing with exercises is not only harmful for health. It switches focus from work to exercising. If you have friends who show these symptoms, try to talk them out of the exercising madness, if they agree, and help them look at their life from the perspective of holistic personal energy management. There’s a great book that can help with that. We don’t need the overstrain and depression from exercising ourselves to death. This is not a war, and there’s no way that someone will put up a monument on our grave for that. We need some sort of light activity, and it’s a matter of personal preference. As for me, I’d rather prefer not to expose my spine and joints to unnecessary physical load. Sitting in a chair, no matter how ergonomic it is, is bad for our spines, so I’m particularly sensitive about all things spine, and I’d rather do some soft exercises, such as yoga postures, or stretching (I’ve got the whole baggage of cool tennis stretches from the years of my practice :), or use a fitness ball. Or, walk and swim. Skipping, biking, or, God forbid, jogging on a concrete are my least preferred kinds of physical activities. Another bottomline thing is that the healthcare bills are not ethereal. They are real. So, if we do not want to end up being healthcare bankrupts by our 50′s, it’s better to use caution about exercising as early as in the 20′s, or at least 30′s.
Last week-end I had a flashback to this do-or-die exercise mindset. I was walking barefoot in Delaware Park, enjoying the feel of grass and fresh air after the rain, the landscape was so serene, and there were not too many people in the park. Then, I saw a massive guy, who was obviously doing some sort of plyometric training, running uphill in sprints. He was huffing and puffing, and, as I sat nearby, I could hear some hard-and-push music from his earphones. Well, his huffing and puffing was actually breaking the serenity of the moment, but I could definitely empathize with this guy, because he reminded me of those days when I used to be like that myself. Then, after a while, the guy was done with his training and, as if sensing my discomfort, said to me as he passed by: “Now you can have it all to yourself”. I laughed and said: “I hope your workout was good!” He didn’t answer and looking at him one could say that he was rather exhausted than happy and filled with energy after this workout. Then, I proceeded walking barefoot around the loop of the Hoyt Lake, and spotted a beautiful piece of street art as I went:
Now, tell me, who do you think felt recharged and re-energized on Monday? Me or that guy? The answer looks obvious.
Last week one of our stakeholders brought his pug dog, Lola, along to our product review meeting. “Watch out, she likes feet!” he joked but she remained quiet and well behaved throughout the meeting. Unruly is not the only place I’ve come across where dogs have been accommodated at work, another had a dog basket in their main board room. I appreciate not everyone likes dogs around but I like working for a company that’s not too stuffy to allow people flexibility to make our workplace more homely.
We’re lucky at Unruly to have a dedicated People & Places team who work closely with our Design team create a work environment that has personal touches. There are many informal meeting places around the building to make collaboration easy and it’s decorated with original artwork reflecting our culture. Little things amaze visitors as we show them around, for instance we created a two-way webcam portal between our London and New York office with a gold antique-style frame, which makes it seem more special and echoes Harry Potter where characters move around. What’s the business case? Creating an environment that allows human expression encourages creativity to flourish in our work.
The design of our workspace is not owned by a central team outside development. We recently reorganised our desks and unlike many companies, where a "Desk Move" is a dreaded logistical nightmare involving packing things up for another team to execute overnight, our developers simply got stuck into disassembling desks and lifting floor tiles themselves to get everything in the right place. Our spirit of collective ownership and taking responsibility for how our code structured seems to extend out to our surroundings. Taking care of our workspace, isn’t somebody else’s job.
Our teams use our walls and whiteboards for practical purposes but with a sense of humour too. Even electronic tools get a bit of customisation, we use Trello for our backlogs and teams can add distinctive backgrounds to make them easier to pick out.
Teams in bigger companies often find that their boards are the easiest areas to start personalising, when you introduce Kanban boards you can involve everyone on the team in designing the layout. Rather than diving straight in to moving things around, you can create a mini-version of the new layout with sticky notes. I think it’s important to give everyone on the team the opportunity to mull the proposed design over and allow time for tweaks. We’ve taken this approach with how we lay out our boards and our desks (as in the examples below).
I appreciate that many people work in organisations that don’t actively support personalisation of the workspace but you can start small with a potted plant, a team mascot, a little whiteboard artwork. You'll likely find personal touches are noticed and soon start to spread around surrounding teams. Another small step that you can take is to adopt iteration names or pictures that pick up on what’s going on in the outside world or reflect metaphorically on current mood within the team. In software development, we spend a lot of time in an office environment, taking care of your surroundings helps to take care of the people working within them.
If you’ve been paying attention to agile at all, you’ve heard these terms: pairing and swarming. But what do they mean? What’s the difference?
When you pair, two people work together to finish a piece of work. Traditionally, two developers paired. The “driver” wrote the piece of work. The other person, the “navigator,” observed the work, providing review, as the work was completed.
I first paired as a developer in 1982 (kicking and screaming). I later paired in the late 1980′s as the tester in several developer-tester pairs. I co-wrote Behind Closed Doors: Secrets of Great Management with Esther Derby as a pair.
There is some data that says that when we pair, the actual coding takes about 15-20% longer. However, because we have built-in code review, there is much less debugging at the end.
When Esther and I wrote the book, we threw out the original two (boring) drafts, and rewrote the entire book in six weeks. We were physically together. I had to learn to stop talking. (She is very funny when she talks about this.) We both had to learn each others’ idiosyncrasies about indentations and deletions when writing. That’s what you do when you pair.
However, this book we wrote and published is nothing like what the original drafts were. Nothing. We did what pairs do: We discussed what we wanted this section to look like. One of us wrote for a few minutes. That person stopped. We changed. The other person wrote. Maybe we discussed as we went, but we paired.
After about five hours, we were done for the day. Done. We had expended all of our mental energy.
That’s pairing. Two developers. One work product. Not limited to code, okay?
Now, let’s talk about swarming.
Swarming is when the entire team says, “Let’s take this story and get it to done, all together.” You can think of swarming as pairing on steroids. Everyone works on the same problem. But how?
Someone will have to write code. Someone will have to write tests. The question is this: in what order and who navigates? What does everyone else do?
When I teach my agile and lean workshop, I ask the participants to select one feature that the team can complete in one hour. Everyone groans. Then they do it.
Some teams do it by having the product owner explain what the feature is in detail. Then the developers pair and the tester(s) write tests, both automated and manual. They all come together at about the 45-minute mark. They see if what they have done works. (It often doesn’t.) Then the team starts to work together, to really swarm. “What if we do this here? How about if this goes there?”
Some teams work together from the beginning. “What is the first thing we can do to add value?” (That is an excellent question.) They might move into smaller pairs, if necessary. Maybe. Maybe they need touchpoints every 15-20 minutes to re-orient themselves to say, “Where are we?” They find that if they ask for feedback from the product owner, that works well.
If you first ask, “What is the first thing we can do to add value and complete this story?” you are probably on the right track.Why Do Pairing and Swarming Work So Well?
Both pairing and swarming:
- Build feedback into development of the task at hand. No one works alone. Can the people doing the work still make a mistake? Sure. But it’s less likely. Someone will catch the mistake.
- Create teamwork. You get to know someone well when you work with them that intensely.
- Expose the work. You know where you are.
- Reduce the work in progress. You are less likely to multitask, because you are working with someone else.
- Encourage you to take no shortcuts, at least in my case. Because someone was watching me, I was on my best professional behavior. (Does this happen to you, too?)
The effect of pairing and swarming is what improves your products. The built-in feedback is what creates less debugging downstream. The improved teamwork helps people work together. When you expose the work in progress, you can measure it, see it, have no surprises. With reduced work in progress, you can increase your throughput. You have better chances for craftsmanship.
You don’t have to be agile to try pairing or swarming. You can pair or swarm on any project. I bet you already have, if you’ve been on a “tiger team,” where you need to fix something for a “Very Important Customer” or you have a “Critical Fix” that must ship ASAP. If you had all eyes on one problem, you might have paired or swarmed.
If you are agile, and you are not pairing or swarming, consider adding either or both to your repertoire, now.
In Project Management, if one thing is for sure, it’s that nothing is certain. You can try to plan everything to a ‘T’ and account for every possibility, but there will invariably be things that pop up unexpectedly. Sometimes this leads to project managers thinking, “If only I held more planning meetings and spent more time talking things over with my guys, then their best laid plans wouldn’t go awry“. Instead of looking back at the project planning as the issue, we can perhaps learn more by better understanding the nature of uncertainty itself. Uncertainty is a very important topic in quantum physics and understanding the nature of the universe. Since Scrum already uses some physics terminology, like velocities and projected values, I thought it would be fun to run with this idea and take some of the implications of quantum physics and see how they would translate if applied to project management.
Before Breaking Bad brought him back, most of us remembered Werner Heisenberg for his uncertainty principle from high school physics. Mostly that you can you can never fully know the position and momentum of a particle at any given time. This is often misused or confused with the ‘Observer Principle’ meaning that you can’t measure something without actually affecting its outcome. For example if you have an electron traveling in space, the only way that you would be able to detect it would be by having it react with some other particle or detector that would then relay that information back to you.
In order to detect an electron to tell us where it is, we have to transfer or absorb some momentum from the electron, thus changing its momentum. It’s like if you have an overbearing manager demanding constant status updates. Just by getting a status update (taking a measurement to get the team’s position), he or she is consequently affecting the team’s momentum.
So what does the observer effect have to do with uncertainty? Nothing, really, but it’s often misrepresented as a result from uncertainty, so I thought I would address it first. This principle also has common classical examples, like how you can never accurately take your temperature using a mercury thermometer. Because the heat from your mouth flows into the thermometer and slightly cools your body, you can never get a truly accurate measurement.
Heisenberg’s actual uncertainty principle is represented by the formula:
Δx · Δp ≥ ℏ/2
Where Δx is the uncertainty of position, Δp is uncertainty of the momentum, and ħ is Plank’s constant over 2π. If either of these values were completely knowable, then the right side of the inequality would be 0, rather a constant! The fact that it is a positive number means the more you know about an object’s position, the less you can know about its momentum. Granted ℏ is an extremely small value (~1 × 10−34 J·s !), but the more you are checking up on a team’s progress there comes a point where you’re not learning anything new and are just affecting their momentum.
A lesser known relationship (and one that also has implications in Scrum) is:
ΔE · Δt ≥ ℏ/2
Notice that it has the exact same form as the previous equation. That’s because these are conjugate variables and also have to abide by the limit of uncertainty. Just as there is an inverse relationship between the uncertainty of position and momentum, there is a similar relationship between energy and time. The more you know about how much work is required for a particular task, the less you know about the time it takes to complete the task.
Many Scrum teams already account for this by using Story Points for estimates rather than using hours. Story Points removes the rigid constraint of estimating work in hours, and instead allows estimates based on similar user stories you’ve done in the past. I’m not saying that one method is better than the other, or would be the best for your team, but you’re not constrained by cosmic forces like uncertainty.
Since Scrum is an iterative process, you can have great success by focusing on things that you can say with a fair degree of confidence, while still allowing for some uncertainty in all planning and estimates.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
So, you want to be an Agile shop. You’ve read all kinds of cool stuff about Sprints, and WIP limits, and daily stand-up meetings. You even think you get this crazy User Story and Planning Poker stuff. You put together a room with snacks and lava lamps. You have all of your stories in a cool ALM tool like VersionOne and displayed on a wide screen TV. So you’re ready to go, right? Well….maybe not. You are missing the most important part….the people. Remember that one of the principles of the Agile Manifesto is to “Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.” In order to be successful, we need more than just motivated individuals, we need motivated Craftsmen.
Lets start with a disclaimer. I use the term Craftsman in a gender neutral sense. If folks feel like I should change this to Craftspeople, let me know and I will. I get a lot of inspiration from the Software Craftsmanship movement, which tends to use the word Craftsman.
So what is a Craftsman, and what does that have to do with Agile? Agile is hard. It is a very highly disciplined approach to software development. It also is very fast moving. If we expect to be able to “welcome changing requirements, even late in development”, we need to have people with a high degree of skills in order to do that. A craftsman is someone who takes the craft of programming seriously. One who will not do garbage work, and will not accept garbage from her peers. Lets take a look at the values delineated in the Agile Manifesto:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
We’ve all seen these many times, but let’s now look at the Craftsman’s Manifesto. You can find a link here: Manifesto for Software Craftsmanship
Not only working software, but also well-crafted software
Not only responding to change, but also steadily adding value
Not only individuals and interactions, but also a community of professionals
Not only customer collaboration, but also productive partnerships
So really, they are symbiotic. A well performing Agile shop will have Craftsmen as the vital part of their team. A team of Craftsmen, by their very nature, will be embracing those values and principles of the Agile Manifesto. So don’t forget the people as you build your Agile shop. Create an environment that encourages those great practices like Test Driven Development and Continuous Integration. Allow your team members the freedom to practice their craft, and the opportunities to enhance their craft. In the end, you will have your motivated individuals who will delight in getting the job done.
Now that I’ve had a week to reflect and let the experience sink in, I wanted to share my thoughts of our first official Baltimore Lean Coffee event.
I’ve participated in ALN DC events and even helped organize a PMI Agile meetup. So, where did our new event fall on a scale compared to the others? Did I feel like attendees received value and did I feel like we got a good return on our investment? Let me give a little comparison.Lots of effort – Too much process – Formal – Minimum ROI
WDCPMI (Washington DC PMI) Agile meetup is a more formal event that is trying to get its legs. Cost will vary, depending if you’re a PMI member or not. It’s targeted to the Washington DC project manager community. To be a host, you have to ask permission to hold an event and jump through some hoops with the local PMI Chapter. It’s a PMI evening event, so you can’t simply order pizza. It gets catered. You have to make sure you’re compliant with PMI Chapter processes. To me, the process and effort put into organizing and holding the event is not worth the value it delivers.Less effort – Not too much process – Less formal – Good ROI
ALN (Agile Leadership Network) DC is a semi formal event that happens once a month in the evening. For $10, you get an evening of pizza, an opportunity to interact with others, and listen to a guest speaker. I like it because it’s casual and it’s good to see others from the local Agile community. What I don’t like is it’s in Washington DC and it’s in the evening. For those who want to see their families after a long day, this can be an inconvenience. I’ll admit, I am not an organizer for this event. I don’t know how much overhead is involved. (I would love to hear from someone in the comments) The group does a good job of not letting the process get in the way.Minimal effort – Minimal process – Informal – Maximum ROI
Baltimore Lean Coffee is a structured, but agenda-less meeting. Participants gather, build an agenda, and begin talking. Conversations are directed and productive because the agenda for the meeting was democratically generated. We don’t charge anything to join us. If you want to grab a cup of coffee (or other beverage) and a pastry, that’s up to you. Our meeting was 07:30-09:00 on a Friday, allowing people who had to go into an office (or even work from home) time to join us. The last voted topic of our meetup was the time and location. In true Agile form, we discussed it, voted, and decided we liked the time and location. Our next meetup is August 8th back at Mad City Coffee.
I've listed a whole series of Kanban Coaching Professional (KCP) Masterclasses for the 2nd half of 2012. These classes are typically residential and can be consumed as 2 x 3-days or in a single 5-day week long intensive class. Typically 4 out of 5 people are choosing the 5-day version of the class since we introduced it at the beginning of 2014. These classes are a big commitment in time and money and we often get asked where the value is? I'd like to explain.
Success has many fathers! Recently, there has been some content published elsewhere on the web that seeks to re-write the history of the adaptation of kanban systems into the field of creative knowledge work. The individuals publishing these alternative versions of history are generally doing it for self-serving reasons or in some cases as deliberate misinformation to try and undermine my business. To put the record straight, I've compiled this definitive history...A History of Kanban for Creative Knowledge Work October 2004
Dragos Dumitriu, manager XIT Sustaining Engineering at Microsoft, asks me to help him. I design a pull system for Dragos' group and coach him on how to introduce it. He "sells' the idea to his bosses and his 4 product managers who act as his customers. The pull system was implemented on Microsoft Product Studio (a forerunner of Team Foundation Server). There was no physical board. The engineering team was offshore in Hyderabad, India. The system implemented was inspired by Theory of Constraints Drum-Buffer-Rope and worked on the assumption that Test was the bottleneck.
Fred Brooks warned us of these dangers nearly 25 years ago in The Mythical Man-Month.
One antidote to the PM schedule crunching technique of throwing warm bodies at the problem is to remove the impediments that are known (or just under the surface) within the structure and environment that holds the team back from performing at more efficient delivery rates. So many times the line workers (developers and testers) are well aware of these issues, and feel as if they have raised them many times and gotten little attention (mostly negative attention) from managers. A classic game (Innovation Game) to expose these impediments is Speed Boat.
I just saw this image of the anvil holding the balloon down and thought it would make a great visual metaphor for the Speed Boat game. See the article by Alan Dayley Velocity is Like a Helium Balloon to get a hi-res poster.
WARNING: Shameless plug for my session at Agile2014 ahead.
I recently got the priviledge to listen to Alistair Cockburn talk to a small group at the VersionOne offices. He told the story about Kent Beck and how the idea of how the user story on notecards was born (I’ve read about this before, but it was great hearing it from Alistair). He talked about how the card was just that — a card with a title that reminded the developer and the target customer/user what they were building, maybe there were a few notes jotted down on the card. The narrative about the story wasn’t captured on the card — the details were verbally communicated because the developer and customer were all in close proximity of one another — they did this crazy thing, they simply walked down the hallway and talked.
In addition to this story, Alistair spoke about his experiences with a team that had development in Singapore and the business folks and architecture worked in the states. The company was having challenges with the team in Singapore at getting things done efficiently and, in some cases, getting things done right. It seemed like there was an inordinate amount of time that had to be spent on discussing requirements and getting questions worked out. The company decided to send some of the business and architect team members to Singapore to work out some improvements. When they did — the quality and productivity went up. When they returned, it took just a couple weeks before productivity slipped and all gains were lost. The reason for these results seems obvious — timezones, communication barriers, and not being able to have impromptu conversations can have a great impact on how well teams understand the requirements especially since a lot of conversations capture the specifics.
Hearing these two stories triggered some ideas in my head, and I thought — why can’t there be a simple formula we can use to gauge the amount of detail (words) we capture in a story to make it work. Through some hard work — I’ve now have that formula.
Here are some factors that I think go into figuring this out:
- Complexity – just how well does the team understand the story and how hard the team thinks it will be, either from experience or flat out guessing. Usually captured as story points.
- Difference in Timezones – the number of hours that separate us greatly impacts how fast communications can happen, especially if the communications occur near the bookend points of the day.
- Auditing Requirements – audits are generally costly and require an additional amount of documentation overhead.
- Multiple Offices – when people are in different buildings, it raises the amount of details that have to be captured.
- Offices on Different Continents – although this somewhat relates to timezones, there is also the fact that people speak different languages. Even if they all agree to use english as the primary business language, there’s still slang, accents, and even cultural differences that impact communications.
How Long the Team has Worked Together – knowing each other is key, we figure out accents, we are able to exchange less verbal words, and we learn how to work with one another — what level of information is required to work effectively as a team.
So I reached out to some friends and the folks at Tagri Tech, and with their help — here’s the formula we came up with:
Amount of Words in Story = (Complexity * (1+ max absolute difference between timezones) * (1 + # of annual audits) * (Total # of locations * # of continents)) / (# of quarters the team has worked together)
And here’s the formula in action:
Multiple simulations have been ran and I found that the formula works in less than 0.01% of the situations. The people I’ve been working with at Tagri Tech’s statistics analysis department have ascertained that every team is different, and every product is different — this means that no matter how much documentation you have — the people involved in creating the documentation or the target consumer of the documentation really are not going to read it. They found that while some documentation like compliance reporting and end user documentation are necessary, much of the collaboration level docs are only consumed by the person that created it.
Ultimately, Teams will generally work together to figure out how much details are truly required to facilitate working effectively. If your teams are having challenges with how much documentation is required within Agile Software Development projects, then please come to Agile 2014 and check out my session on Friday at 9AM in the Sanibel room, we’ll talk about some ways teams can workout their own formula.
Update: Hopefully you read all the way to the bottom of this post and realize, this is just a ruse, a joke, a farce, me not being serious. My point is, agile is hard and the concepts of documentation around building software makes it difficult as well. The right amount of details in our requirements is a trial-and-error thing, sometimes you’ll have too much details and at times too little.
In preparation for my talk, Agile Projects, Programs, and Portfolio Management: No Air Quotes Required, I have created a Minimum Reading List for an Agile Transition. Note the emphasis on minimum.
I could have added many more books to this list. But the problem I see is that people don’t read anything. They think they do agile if they say they do agile.
But saying you do agile doesn’t mean anything if you don’t get to done on small stories and have the ability to change. I hope that if I suggest some small list of potential books, people will read the books, and realize, “I can do this!”
I am probably crazy-optimistic. But that hasn’t stopped me before.
I would like your help. Would you please review my list? Do you have better books? Do you have better suggestions? It’s my list. I might not change my mind. However, if you comment on that page, I would know what you think.
Thank you very much.
Forgive me for bringing up show tunes. I love the old musicals. One of the true classics of American theater is the show Oklahoma. I got to thinking about this in a very roundabout way the other day. The song, called “With Me It’s All or Nothing” got stuck in my head. Let me tell you why…
If you like to cruise the various discussion groups, you will find to time see a question “When it comes to Agile practices, which ones should I do first?” or “Which Agile Practice is the most important of all?” These questions are fun to argue about. They are mental candy. But the bottom line is, just like candy, they can also be bad for you. If we decide that iterative and incremental development is the most important aspect of Agile, does that mean we can get rid of Test Driven Development? Or, if we decide that Continuous Integration is the most important practice, does that mean we can break out the Gantt charts? I don’t think it does.
The most egregious example I have seen in this, and it is unfortunately quite common, is the mistaken belief that we can do all of those nifty Scrum ceremonies and activities, and ignore the development practices that make Agile work. If you have an iterative process that embraces change, even late in development, but have none of the practices that make that possible, you just have a lot of tired, frustrated programmers. This may be the source of some comments we’ve seen on this blog lately that say “I hate Scrum”. I often wonder if it is Scrum that these folks hate, or if its the fact that only part of it is being used.
I’ve always seen Agile, or more specifically the implementation of Agile, as a whole package kind of deal. The real power of Agile software development is not the fact that you do things in smaller increments, or that you write your code test first, but in the supporting power of each of these elements. The whole is so much more than the sum of its parts, that I can’t understand why one would chose to not implement the whole thing. Its sort of like buying a pepperoni and mushroom pizza, then picking off all of the mushrooms. If you didn’t want mushrooms, why did you order the pepperoni and mushroom?
This all came about because of a rather heated discussion around what is more important, Acceptance Test Driven Development, or Unit Test Driven Development. The “antagonist” in this argument was contending that since the Unit Tests are “just for the developers” they really were unnecessary, and Acceptance Tests were all that was required. After a while I couldn’t help but ask “why are we arguing about this?” The real answer is we need Acceptance Test Driven Development, we need Unit Test Driven Development, Refactoring, Continuous Integration, and yes, Pair Programming. You see, with me it really is All or Nothing.
I have an article in a new online magazine, Women Testers, the July 2014 edition. My article is called “Why Testing?”
When I was a tester or a developer, I asked many questions. As a project manager, program manager or consultant, I still ask many questions. One of those is the Why question. This article examines that question from a number of perspectives.
I bet you’ll enjoy it!