Subscribe to AgileIQ via email

Your email:

Subscribe to our Newsletter

siq newsletter 180

AgileIQ Blog

Current Articles | RSS Feed RSS Feed

The Importance of Slack in Achieving Speed and Quality


by Steve Bement

The importance of slack in Agile software developmentSlack is an Agile practice (coming from Extreme Programming, or XP, which falls under the Agile umbrella) that we haven’t talked about much. What is slack? In common usage it probably has a negative connotation, as in “he has been slacking off”. But in planning for successful sprints that yield consistent, high-quality results, it is essential.

Here’s an explanation from James Shore in his book The Art of Agile Development:

“Imagine that the power cable for your workstation is just barely long enough to reach the wall receptacle. You can plug it in if you stretch it taut, but the slightest vibration will cause the plug to pop out of the wall and the power to go off. You’ll lose everything you were working on.

I can’t afford to have my computer losing power at the slightest provocation. My work’s too important for that. In this situation, I would move the computer closer to the outlet so that it could handle some minor bumps. Your project plans are too important to be disrupted by the slightest provocation. Like the power cord, they need slack”.

Slack can help us consistently deliver on our sprint commitments, and deliver high quality software. Slack goes hand-in-hand with other Agile practices such as continuous refactoring and emergent design. Here’s how it works: throughout the sprint your team follows the practices of emergent design and refactoring. Then see what your resulting velocity is. Use this velocity in future sprints, so that time for good design and refactoring is built in.

It may be non-intuitive at first, but these practices will help you go faster in the long run. Refactoring is a way to pay down technical debt. If you don’t continuously pay down this debt, the design of the code deteriorates and the software becomes brittle (hard to change). This makes you go slower. On the other hand, if constant attention is paid to design, through refactoring, the code becomes easier to change, which increases velocity.

With these good design practices built into your sprint, you have some room (some slack) when emergencies come up. In these cases, you may put off some refactoring in order to meet your sprint commitment. However, you have to use this option wisely (and rarely), or technical debt will start building again. If you find you are consistently putting off needed refactoring, you don’t have enough slack.

James Shore also said: “By varying the amount of time you spend paying down technical debt, you can assure that most iterations come in exactly on time”. Slack gives you this assurance, and also yields higher quality code with a good design, allowing you to move faster.

For further reading, see Tom DeMarco, 2002; Slack: Getting Past Burnout, Busywork, and the Myth of Total Efficiency.

What Sets SolutionsIQ Apart?


by Kathy Simmons

Learn how unique SolutionsIQ is and what differentiates us from our competitors! We have a depth and breadth of Agile talent and services that you won't find anywhere else.


For greater insight our culture, check out these videos of recent company gatherings!

Tags: , ,

An Introduction to DevOps


by Laszlo Szalvay

Traditional IT groups have responsibilities in two areas: Apps and Ops. The lines between them are becoming increasingly blurred. Watch as Laszlo explains where we see the market going.

Tags: ,

Why We Do Test Driven Development


by Blake Lindsay

At SolutionsIQ, our developers practice Test Driven Development (TDD) to deliver well. Learn why TDD makes great business sense.


Test-Driven Development and the Discipline of Juggling


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.

test driven development jugglingI 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.

Facilitating Meetings That Get Results Every Time


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.

Steven M. SmithIn 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.”



Some Questions for Agile Developers


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.


Task Sizing in Agile Software Development


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.

task sizing agile software developmentHow 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.

Visualizing Work: The Video Task Board


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”.

Video Kanban boardVideo Kanban board

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.

Agile and Trust


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.

Agile and trustMs. 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.

Tags: ,
All Posts