by Blake Lindsay
At SolutionsIQ, our developers practice Test Driven Development (TDD) to deliver well. Learn why TDD makes great business sense.
by Steve Kuo
People who know me know that I like analogies. I have many to describe Test-Driven Development (TDD) and how I use it, one of which is relating it to juggling. Here’s how I explain it:
To me, writing code can be a lot like juggling. I write a method that is 15 lines of code. I consider this method to be the equivalent of one ball. Almost all people can juggle one ball with two hands — it's essentially handing it back and forth.
Next I write Method2, another 15 lines of code, that interacts with Method1. Slightly more complexity but still straightforward. In my head, I can keep track of those 30 lines of code and how they interact. It's now the equivalent of juggling two balls. I can keep an eye on both balls, two hands, just a simple toss to switch them. Harder than one, but still doable.
I add in Method3 (another 15 lines) that is called by Method1 and Method2. Changes that I make in Method3 must not break anything in Method1 and Method2. Also, changes that I make in Method1 and Method2 can’t break what’s done in Method3. Lots more complexity and code to keep track of in my head. A lot like adding a third ball to juggling. Now I have to keep one ball in the air at all times, transfer another ball, and throw the third. I do know how to juggle — just like programming, doable. I almost never drop a ball... or introduce a bug.
Here’s where my juggling skills max out, though. When I try to add a fourth ball, I can’t juggle for long without dropping some balls. Not only do I now have two balls in the air, but I have to change my juggling technique. Similarly, when writing code you could add Method4 or even a new Class that calls or inherits from the original Class. A lot more complexity happens then. More things to keep track of and, as we all know, everyone has a limit to how many balls they can juggle at once.
Now let me explain how TDD works to help me juggle many balls. Even before I write Method1, I start writing tests to drive my functionality. Those tests are the equivalent of the ball being smart enough to juggle itself and knowing where it needs to go automatically. It never falls because my tests are ensuring that it “juggles” correctly. With tests supporting all the balls, an infinite number of balls can be juggled with no problem.
Because my methods are supported by tests, I know that not only that I did not break the functionality of the method that has my full attention and that I am actively modifying/writing — I no longer have to keep track of the litany of other functionality that I might impact in other methods and classes. The other methods have their own tests and can take care of themselves. It’s liberating not have to worry and try to remember everything about the entire codebase. I can focus on the important parts — the parts that I’m directly working on — and how to improve them.
Some people like analogies and some don’t. Not every analogy is perfect, either. I like this one and it generally holds true. With TDD, I don’t need to focus on keeping all the balls in the air, making quick transfers, and catching. TDD enables me to focus on juggling one ball at a time. All the other balls will know how to juggle themselves and let me know if something goes wrong.
by Pam Dyer
Meetings can be powerful accelerators when a company wants to build alignment, deploy strategy, get work done, and accelerate/deepen organizational transformation. Solid facilitation skills are key to achieving results — someone has to shape and guide the process of working together so that you move through the agenda, meet your goals, and accomplish what you've set out to do.
In a recent Wall St. Journal article, SolutionsIQ Agile consultant Steven M. Smith reflected on the role of meeting participants in making sure that conference calls are leveraged to their full potential:
“Participants can help meetings run more smoothly by volunteering to serve as moderator, keeping people on-topic and sticking to time limits. Divvying up moderating and note-taking duties can free meeting leaders to participate and keep people engaged ... Some managers encourage any participant to moderate, breaking in if a speaker wanders off-topic and asking that everyone stick to the agenda, says Steven M. Smith, senior consultant in Seattle for SolutionsIQ, a management consulting and training firm.”
Read more at WSJ.com
by Dave Wylie
Are you a smarter Agile developer than you were last year? Have you learned a new scripting language or a new functional language? Have you participated in a hackathon and seen how people can stitch together amazing stuff in 24 hours? Are you ready for mobile to overtake laptops this year? Become more valuable and you will get paid more.
by Steve Kuo
We are commonly asked how big our tasks should be. That should be a pretty simple question to answer. How big is too big for a couch to fit into my house? Simple -- how large are your doors and does the couch come apart? Determining how big our tasks should be is a little bit more complicated than that, though.
How big is too big for a task on an Agile development team? How small is too small? How would Goldilocks pick a story that is “just the right size”? In a lot of ways, the answer is do what works best for the team. With that said, what we’ve seen work very well across many different teams in many different industries is: Keep your task size to one day or less. Breaking tasks down to one day or less exposes enough detail to define the boundaries, but not too much design to constrain ideas and take a lot of time to plan. It also seems to help mitigate estimation error as well. There are some costs and risks involved with breaking tasks down this small though.
People are notoriously bad at estimating the time and effort that any task will take because a significant part of the estimation process involves intuition. Domain/subject matter experts and experienced senior people can provide slightly more accurate estimates, but they are not significantly better than those of less senior technical people.
In some ways it’s as much human nature to want to know exactly how long it will take to do something as it is to not be able to answer that question accurately. We’re bad at it but we need to do it, so how do we work with it? By balancing the duration of the time estimate with the amount of time it takes to define the work. The greater the time, the more likely our time forecast will be off. And the more time it takes to define the work and the greater detail we design, the less efficient and adaptable we are when we implement the work.
This is why breaking tasks down to one day or less works well. Doing this lowers exposure and lessens the risk of bad intuitive guesses. Limiting task size to one day or less lowers the amount of time affected by our innate inability to accurately predict work and effort, while increasing possible feedback cycles and visibility. The discussion and knowledge required to break tasks down to one day is enough to expose problems that would cause the task to take longer than a day. When a task is mis-estimated and goes longer than a day, it generally spans multiple stand-ups and becomes visible to the team. This feedback gives the team an opportunity to reflect, adapt ,and offer help. The amount of time that the task breakdown discussions take, although initially longer, tends to quickly be acceptable to developers.
There are some caveats to breaking down tasks to small sizes, though. When breaking down tasks to one day or less, it often takes conscious thought to not design and get distracted and go “into the weeds” while tasking. There will be many “small” tasks to track and maintain. This is a necessary evil, though, and while this can be a bit tedious it does increase visibility/accuracy and shortens the feedback loop. Initially, breaking tasks down to one-day chunks will take a little extra planning time, but as the team becomes more practiced in this skill it will become second nature and not take longer.
by John Chalverus
To do, In Progress, and Done: The simplest way to visualize work on a task board.
For me, some of what it means to be Agile is staying flexible, adapting things to your needs, and continually improving and reflecting on what works and what doesn't. When I first joined SolutionsIQ, my position didn't fit nicely into a box. Of course, this would be expected of a company striving to be innovative and Agile at its core. I do a combination of marketing, branding, and video. The video part was new for everyone, and consisted of creating content for the Web and for social media to support Marketing. Early on there was a lot of enthusiasm for what I do, but a lot of people didn't understand what was involved in making a finished published piece. Part of my work is very visible, such as when I'm filming, but there are also a lot of heads-down tasks involved, e.g. when I’m sitting at my computer editing.
I found that a task board is a great solution for communicating what my work involves, as well as how it is progressing.
At first glance it can seem a bit complicated, but there is a simplicity underlining the specifics of my work. If you take a step back, it still has the basic “To Do”, “Doing”, and “Done”.
The left site of the board starts with content ideas. Ideas turn into stories, which are filmed, edited, and uploaded online. The right side completes the process with a list of finished videos and their links. All of this is visible to anyone in the company.
In the next post, I'll go into the specifics of the columns and how to balance communicating enough information without feeling like everything you do is a column.
by Dan Williams
In a recent TED talk, noted philosopher Baroness Onora O'Neill addressed what she considers a faulty viewpoint concerning the concept of trust. In her opinion, the claim that there has been a great decline in trust is without factual basis. Further, based on this faulty assertion, people recommend that our goal should be to have more trust.
Ms. O’Neill went on to say that all of these ideas were misconceived, and that the claim was mere opinion and could not, as far as she knew, actually be substantiated. We seem to trust and distrust the same folks we always have. We generally distrust politicians and journalists and tend to trust nurses and librarians. Her point is that we trust others based on what we know of them. And this is entirely reasonable.
Secondly she states that the goal of having more trust is off the mark. We don’t need to simply increase trust in others, but rather find people who are trustworthy. We don’t need to trust more, we need more people in whom we can trust. Who are these people? Well they are at least competent, honest, and reliable. And they need to be all three.
So how do we establish trust? Empirically! Through observation over time. People doing what they say they will do. People delivering with prior agreed-upon quality. Trust is one of the identified values which informs an Agile approach.
Jeff Sutherland, one of the creators of Scrum and a signer on the Agile Manifesto is quoted as saying,
“To create high-performing teams, agile methodologies value individuals and interactions over processes and tools. Practically speaking, all of the agile methodologies seek to increase communication and collaboration through frequent inspect-and-adapt cycles. However, these cycles work only when agile leaders encourage the positive conflict that is needed to build a solid foundation of truth, transparency, trust, respect, and commitment on their agile teams.”
I believe that Sutherland and O’Neill would agree on both the method and the goals of Agile. Vulnerability is good evidence of trustworthiness. My assertion is that Agile, as a mindset not a set of methods, succeeds or fails based on establishing our trustworthiness as individuals and teams who consistently deliver value to our clients.
by Pam Dyer
Leading technology organizations are transforming the way they manage their server environments by using software automation rather than manual administration.
On December 10, Ben Tomasini — SolutionsIQ Software Developer and Agile Coach — presented Agile DevOps: Environment Automation. He walked through a working example of this practice using Chef, Vagrant, Berkshelf, and other industry-leading tools, with special focus on the use of Test-Driven Development and Continuous Integration.
You can use the sample codebase Ben employed in the webinar to jump start your own Agile DevOps practice.
Agile DevOps: Environment Automation from SolutionsIQ on Vimeo.
by Bryan Stallings
When the voices of the ScrumMaster and product owner reside in a single person, it's very confusing to the team.
by Phillip Cave
Continuing the “Principles of Done” series, this post explores the difference between being effective, efficient, and busy. (See Parts 1, 2, and 3.)
A story I like to tell is about working with a group at Microsoft. One of the PMs I collaborated with had a team that was faced with an ever-changing environment and specialty-based team members. During a standup, it was brought to the team’s attention that a story was blocked because the specialty team member was busy setting up his test environment. The team asked if he had to be the one to set up the environment. The answer was no, he did not have to be the one to set up his test environment and that, in fact, another team member could accomplish that task while he unblocked the team by working on the story.
Was it efficient for him to set up his own environment? Probably. Was it effective? Absolutely not. This is a story about focusing on the work and not the team member, and reaching the most effective way in which to complete the work. Teams have work and people to complete work. Adding to the complexity, teams sometimes have multiple types of work to perform.
Focus on the most important work and then focus on the most effective means by which to complete that work. This may mean examining a buildup of work in front of an activity and understanding why that buildup exists. It may mean changing how you do work or who does the work, or removing your title and focusing on getting work done. It may mean pairing team members to advance the team’s collective knowledge around a technical domain, a business domain, or both.
When I was at Premera Blue Cross as an internal business process consultant and later an IT leader, I was fortunate to be asked to participate in the Lean leadership program that the company had instituted. I learned many things in that program. Chief among them was how the operations leadership team approached maximizing the effectiveness of paying claims. The operations teams had a large visible matrix of activity and people (the activity title on one axis and team member name on the other). This simple tool allowed leadership to examine at a glance the progress they were making to get team members cross-trained in all areas of the claims model line value stream, so that when a claim came in the door it could be handled by one person (or as few as necessary). This was so that the claim could be paid as quickly as possible without having to hand it off into another queue of work and sit idle wasting precious cycle time.
Use this same principle. Work should not have to sit idle or experience a diminished value for lack of effective approaches to make the work flow.
In a recent coaching engagement, I heard about a team leveraging the efficiency of their software engineers — they were more expensive and the team wanted to handle the cost more efficiently. I asked what was more important. Was it more important to optimize on a title or the product? My advice to them was to think of it economically from the perspective of the product. Sunk cost already exists: You know you must have a certain type of software engineer, for example, so that cost is already incurred. The next order of business is to invest in delivering product effectively vs. using a resource efficiently just because they are paid more. You pay them more because you must pay them more based on market demand. The next economic factor is producing product with the people you have in the most efficient manner possible. It is a choice to be effective at the product level instead of being busy. You can optimize the title or you can optimize the product delivery or a combination thereof. Optimizing on someone’s title is at the expense of the product. Optimizing the product or a blend thereof is NOT at the expense of someone’s title. It may be a matter of pride, but the real goal is for a team effort to ship the product.
It is not more efficient or less expensive to optimize a resource if it means the product is late in shipping, because you incur opportunity costs and miss out on the increased cash flow that shipping would have provided.
Your individual contributor may be happy in the short term at the expense of the long-term goal of the product and that of the company. Given this, it is a wise use of a developer’s time to focus on other activity (such as testing, for example) in order to get the product to a shippable state more quickly.
When you do this, you end up managing the work-in-process to stop starting things and focus on finishing things. Getting to done means focusing on the right activity at the right time to deliver and be done.
In a future post, I will discuss other factors that contribute to not getting done. These include:
- “Carry-over” stories
- Defining acceptance criteria
- Planning for support with project work
- Unclear direction