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