08.29.10
Posted in Agile, BDD, Iterative Development, Pair Programming, Software Development, TDD, Teams, Uncategorized at 7:41 pm by Pablosan
Recently I was honored to have the opportunity to work toward being approved to teach Ron Jeffries’ and Chet Hendrickson’s Agile Developer Skills course. I had my first opportunity to co-teach the class last week. It was a great class and I very much enjoyed working along side Chet and Cheezy, two software craftsmen I respect highly.
If you follow the links above, you’ll notice a theme and, though it’s not explicit in the class’ title, Extreme Programming is a significant influencing factor in the course content. Like most software developers, XP has had a major positive impact on my pursuit of the craft, and it’s great to see the practices hold up so well over time.
The ADS course utilizes some lecture, but it is primarily a hands-on workshop giving participants the opportunity to experience developing high-quality, working software using Agile principles and practices. This is the second time I have experienced the class (the first time was as a participant back in May) and it has remained an intense, thoroughly enjoyable way to either learn the practices for the first time or to delve deeper into Agile. I find it hard to believe that anyone could leave the course without learning a great deal. It is both challenging and insightful.
I think my favorite part of the class are the questions and how they help shape and guide the content. That feedback is crucial to the success of the course (maybe any course) and, as an instructor, I find the questions leave me thinking about these principles long after the class is over.
Next time, I’ll share a couple of the questions and some of those thoughts. For now, though, I encourage you to take a look at Agile Skills Network and consider taking the course. Regardless of where you are in your software craftsman journey, the ADS course will encourage you to push further down the path!
Permalink
07.30.10
Posted in Agile, Journal, Teams at 6:44 pm by Pablosan
I don’t think I’ll end up writing a third “Agile Blindspots” post… there was something that I was feeling very passionate about back in February but, for better or worse, this time I simply waited for the feeling to pass.
It has been a busy year. I knew that new ventures are all-consuming, but knowing it and living it are two very different things. I’m closing in on a full year as an independent consultant, the last six months of which have been with one client. Things have been going great and the client is looking for ways to extend the contract; possibly through the end of the year.
That’s a long time to spend in the same environment, and this comes with a significant danger. In Weinberg’s book, The Secrets of Consulting (you can find the book online, but you’ll probably have to buy it used), he refers to this as “Prescott’s Pickle Principle”:
Cucumbers get more pickled than brine gets cucumbered… A small system that tries to change a big system through long and continued contact is more likely to be changed itself.
I experienced this first-hand in a recent conversation with a friend and colleague who just started working with the same client a little over a month ago. I had just had a closed-door meeting with a member of upper management in which they laid out their plan to address several challenges in their organization. I didn’t completely agree with the plan, but I have worked with this group long enough to know when the decision is final so, except for a few clarifying questions, I accepted the news with very little feedback. As I explained to my friend how this might impact him, his response was “this is the wrong solution. It’s going to cause more problems than it solves!”
My initial thought was “technically he’s right, but he doesn’t have enough experience with this client to know when to accept the inevitable.” And that’s when it hit me: I’ve been pickled.
My job as a consultant is to be a change agent. “Long and continued contact” with a client diminishes my ability to fulfill that role. That is why Weinberg gives the following advice:
To avoid getting pickled, a consultant must not spend too much time with one client. If you can’t avoid this, at least break up the time by working with other clients, even for free… It’s hard to be effective, though, if you’re always switching jobs or clients. Change generally takes both time and continued contact, or at least one of the two. The challenge, then, is how to get the client in long, continued contact with some kind of brine, without the consultant even being present.
The challenge indeed! There is a natural tension: time and continued contact erode a consultant’s ability to affect change, yet affecting change takes time and continued contact. I think there are ways to counteract this and I hope my efforts to do so in my current situation will prove effective. But it is also important to recognize the warning signs and to act in the interest of both your client and yourself.
What are some ways you’ve found to keep your clients “in continued contact with some kind of brine without even being present?”
Permalink
11.01.09
Posted in Agile, Software Development, Teams at 4:23 pm by Pablosan
A few weeks ago, I noticed a theme developing in my Twitter feed. I had some friends tweeting from the Simple Design and Testing conference in Pittsburgh, and another friend tweeting about this blog entry. At the same time, I was working on some XP course material and was reminded of Kent Beck’s words “…[taking] commonsense principals and practices to extreme levels.”
So in the spirit of eXtreme Programming, I propose what I believe to be an interesting thought experiment: if self-organizing teams are good, then we will always treat the team as a unit; never drawing attention to specific roles.
This is interesting because success or failure should be measured as a team. If a developer on the team does a great job, but no working software is delivered, the team failed: therefore, the developer failed. If a tester on the team does a great job of providing test coverage over one, small part of the overall work for an iteration but no Stories are completed, the team fails: therefore, the tester failed. If the Iteration Manager does a great job of removing roadblocks and insuring work is driven from a prioritized backlog, but the requirements are unclear and the Demo fails, the team fails: therefore, the Iteration Manager fails. In short, any individual team member’s success is completely dependent upon the success of the team.
This should lead to a team where the concept of roles is, at a minimum, blurred. The team does whatever is necessary to attain the stated goals: meaning, individuals on the team do whatever is necessary for the team to succeed. There is only one role: team member.
So why is this a thought experiment? When it comes to getting real work done, we need competency in certain skills. It would be difficult — even silly — for a company to list job postings seeking “Team Members” without any specific skill set. We still need experts. We still need people with the specific ability to turn ideas into code; to effectively facilitate a team; to expertly test a system. Those roles, and more, are crucial to making real progress on software development projects.
Being an individual is easy. Working effectively on a team is a worthy challenge. What are some ways you are encouraging your coworkers to become teammates: to put the interests of the team ahead of their own interests/concerns/agendas?
Permalink
10.04.09
Posted in Agile, Journal, Teams at 6:00 pm by Pablosan
One of the great things about my current gig is the opportunity to work with several, high-caliber consultants. The client has put together a top-notch team that has the ability to easily exceed expectations. The client is also a Fortune 500 company with a very long history of heavyweight process. Our job is to codify their particular approach to Agile, while identifying areas for improvement. The importance of a well-documented, repeatable process has been the focus of many, long meetings.
The irony of the situation has not been lost on us. Our job is to create a franchise model of Agile, so that the company can start stamping out Agile teams like a manufacturer churning out Happy Meal toys. This has been the topic of discussion among the consultants over many lunches and dinners, and even during trips to the airport.
Somewhere along the line, one of us observed that “maybe we should look at this as an opportunity to institutionalize flexibility.” This is, of course, somewhat tongue-in-cheek, but I also believe it is indeed our challenge. In fact, I think it is the greatest challenge facing Agile adoption today: how do we make Agile work in a large organization, where conformance, governance, systems integration and the like are valid constraints? It is not enough for a team to know where they are: the organization needs to know where they are, how what they are doing will impact other efforts, how much time and effort is involved, etc.
Several large companies are seeking to provide tools to solve this problem, including one that likes three-letter acronyms that begin with “R”. As far as I can tell, the only thing that has been accomplished so far is to add complexity to an already daunting task. Honestly, I don’t think I’ve ever seen a process problem solved by throwing tools at it, but that seems to be the first and most frequent solution landed on in Corporate America. Yet the problem is real, pervasive, and needs addressing.
So how do we institutionalize Agile without violating Agile’s core values? I’m not sure, but whoever figures it out stands to make a fortune!
Permalink
08.25.09
Posted in Agile, Journal, Software Development, Teams at 1:01 pm by Pablosan
Fail early, fail often: the meme has been floating around for a while now. I tried to find the original source and the earliest mention of the phrase I could find was on Coding Horror. I doubt this is where things began, but it does show that we’ve been bandying it about for several years now.
It is a catchy phrase, and the parallel with “Release early, release often” makes it that much more enticing. While it sounds like sage advice, I believe it is incorrect and it suggests the wrong emphasis.
I understand why it caught on. We in Corporate America have become incredibly risk-averse, fostering a culture that punishes failure severely. Years ago I was in an organization where the fear of failure was so strong that I watched helplessly as a project limped along for two years, sapping precious time, effort and money from other, more promising projects.
Failing early is good. The advice to “fail often” is perhaps dubious, but even more important is that failure is the wrong emphasis. To take this to the extreme, stringing together a series of quick failures does not bring success. In fact, that sounds a lot like reinforcing bad behavior!
The right emphasis – the right thing to cultivate – is an always-learning attitude. If we end with failure we stop short of the benefit: learning from our mistakes.
Thomas Edison, who was not only a great inventor but an inspiring leader, put it this way: “Nearly every man who develops an idea works at it up to the point where it looks impossible, and then gets discouraged. That’s not the place to become discouraged.”
Take a look at your company or your team. Are you fostering a fear of failure? Or are you cultivating a culture that quickly identifies mistakes and seeks to learn from them? The former is easy and ends badly. The latter is arduous, but it will enable your organization to accomplish great things!
Permalink
08.22.09
Posted in Agile, Journal, Software Development, Teams at 7:30 pm by Pablosan
I was recently reminded of a conversation I had with my manager about a year ago. The test tools trainer and I had just finished up a new curricula for a testing tool being rolled out across the enterprise, and teaching these classes gave me some great visibility into our QA groups.
I was frustrated. It looked to me like there were a large number of attendees in these new classes who seemed unmotivated: even apathetic. My final comment to my manager was “they’re just not cut out for the tasks they are being asked to perform. They should be let go.” Yes, it was a harsh statement and I am grateful to have a manager who is willing to listen to my rants and then calmly put me in my place. Her answer was simply “you know, there could be many reasons for their attitude. Maybe they’re working for a very difficult manager.” At the time I pretty much blew off the reply and thought “there is no excuse.”
I was reminded of this through a conversation with a friend who had been dealing with an extremely abusive manager. I was horrified. I couldn’t imagine a “leader” being so demeaning. My friend had loyally followed the company as they moved their offices a couple thousand miles away. He is an incredibly talented developer and knows how to get things done. He continued to work hard while he was being screamed at (literally), being called incompetent (between expletives) and being accused of a poor work ethic: all while working 70 and 80 hour weeks to do his best to meet ludicrous demands. Fortunately he is now employed elsewhere!
Shortly after that conversation I had the displeasure of witnessing another example of a tyrant manager and, again, I was stupefied. How do people like that get promoted to leadership?! Don’t they realize that a hostile work environment kills productivity?
Of course, maybe these leaders aren’t being treated civilly by their upper management. Who knows? As my manager reminded me: I definitely don’t know, and it’s not right for me to judge them.
Isn’t it time that we move on? Aren’t the days of tyrant leaders in Corporate America long gone?! Couldn’t we try, maybe just for a little while, treating our colleagues and subordinates with civility, respect and exercise a little temperance? I think we would all be very pleased with the results… even us judgmental types! 
Permalink
08.17.09
Posted in Agile, Teams at 8:49 pm by Pablosan
This year has been filled with change, especially in my career. Up until the last year or so, I have focused on solid, pragmatic software development practices. I still get to spend some time in that arena, but my attention is now split: I’m also spending a lot of time mentoring teams on solid, pragmatic project management practices. I’m also spending far too much of my time babysitting tools (of course, spending ANY time babysitting tools is too much time), but that’s a story for another day.
A happy side-effect of this new focus is that I have a new soapbox! This will come as no surprise to those of you who know me well, since I am a fairly avid soapbox collector. 
Anyway, here it is:
Project management is not about tracking effort: it is about measuring progress.
As simple as this sounds, I am amazed at how many Project Managers, many with decades of experience, insist on tracking effort and ignore measuring progress. I have an idea as to why: tracking effort is much easier than measuring progress.
The difficulty starts with a required shift in mindset. Changing the way we think about things is hard, especially when the old way of thinking has been reinforced by years of repetition. One way I have found to start down the path of reprogramming my brain is making subtle shifts in the questions I ask. For instance, instead of asking “how long did that take?” I can ask “what benefit did we get from the effort expended?”
This introduces a second problem. While the first question above is easily answered with a “concrete” number (I could chase the rabbit track of “define effort”, but I’ll resist), the second question leads to more questions: what is the benefit we received? Was it a one time bonus, or will it pay back dividends over time? How do our customers perceive the benefit? Is their perception accurate? How can we objectively measure it? Where is the business value? …and many more. In other words, it encourages us to think and requires a great deal more effort.
Asking a question that gives me a number to plug into a spreadsheet may give a fleeting sense of accomplishment. Asking the harder questions forces me to demonstrate progress, which is much more beneficial and proves much more fulfilling.
So, are you tracking effort or measuring progress? Maybe it’s time to start asking the right questions!
Permalink
12.11.08
Posted in Agile, Journal, Teams, Travel at 7:58 am by Pablosan
Today I am wrapping up my visit to London. It has been a great four weeks, though I’m anxious to be back home with my family. Having taught two, very full TDD Courses and coached several teams, I took some time this morning for a personal Retrospective, as my four-week iteration comes to its close.
Of course, while I am in my company’s London office there are still things to be done for the home office. At the top of that priority list right now is, as I’m sure is the case with so many companies in today’s economic climate, a cost-savings initiative. The goal is to have all our courses virtualized in 2009. The idea is that we could make the courses available to more people, more frequently, without incurring the cost of sending the trainers all over the globe. For a company with offices strewn across 5 continents this approach, at least on the surface, seems like a good idea. And, like a good employee that thoroughly enjoys what they do (and appreciates the opportunity to remain gainfully employed), I am giving this new approach a great deal of thought. If this is what I have to do, I want to make the best of it. However, stopping to think this morning, I realized that this move to virtual courses comes at a cost: reduced face time.
During these last four weeks it has been impressed upon me several times, and by several individuals here, that the home office’s willingness to send a “guru” (their word, not mine) to provide training and guidance sends a very strong message: the people here are important to the success of the company. This is quite significant, as this particular office is a part of the company I work for through an acquisition. It is quite common for the people in an acquired company to feel like undesirables. I have seen a shift in their attitude over the last four weeks: call it a spring in their step, the sense of the load being lightened, a renewed sense of belonging. However it is described, it is a very good thing. It is amazing how much more people will accomplish when they feel valued.
There is a second aspect that will also be lost through virtualization. I have made significant inroads in challenging individuals to shift their mindset in small groups over pints in pubs. Two individuals in particular were very opposed to some of the things I teach. I don’t think I changed anyone’s mind, but they are at least considering the possibility that the things I’m teaching might actually have merit. I am convinced that, for these people, that would have never happened in a classroom or in an office setting.
We are social creatures: even down to the most hard-core, introverted, “anti-social” computer geek. The fact that we need to physically be with other human beings cannot be ignored: it’s in our genes. And for this reason, I believe the virtual should enhance the real: not supplant it.
Unfortunately, it is quite difficult to assign a dollar value to these types of benefits and so it is easy for companies to eliminate them: wrong… but easy.
Permalink
10.28.08
Posted in Agile, Iterative Development, Journal, Software Development, Teams at 9:52 am by Pablosan
Back in the mid-nineties, having been introduced to Apple Newtons, Palm Pilots and Wacom’s new tablet-is-the-screen technology (I don’t remember the official name), I started dreaming. It had been several years before this that a conversation about computers with my dad ended with his comment “I’ll use a computer when it starts speaking my language!” He has been using computers for a long time now, so I’m pretty sure he has since lowered his standards. While all of this was swirling around out there like the “breeze of democracy”, I came up with the perfect byline for a PDA: “As easy to use as a piece of paper.”
I’ve been reminded of this tag-line twice in the last week. The first time was while attending a debrief meeting with a company who had unsuccessfully demoed their ALM tool to the company with whom I am currently consulting. We provided them with some valuable feedback, with one of the main complaints being the product’s complexity. I asked them why their product, which is intended for Agile teams, did not more resemble a Card Wall. There are several products out there that do: GreenHopper is an excellent plug-in for JIRA and there is Mingle, which is fairly new, has a ways to go, but is off to a great start.
The second time I was reminded of my tag-line was yesterday, while interviewing with Rally Software here in Boulder. We didn’t go into much detail (we only had 30 minutes), but I shared with them my concern that the current crop of software tools, with a couple exceptions, seem to take what was supposed to be a light-weight, very fast and effective practice, and turn it into an incredibly complex piece of software. They shared with me that, using feedback from their users, they were finding ways to simplify their product. Kudos to them!
So, if using Index cards and slapping them up on a wall is so great, why use a software tool? Here are my answers:
- Don’t use a software tool. Use a Card Wall.
- If your team is not co-located (meaning not everyone on the team will be able to see a physical Card Wall), divide up the project in such a way that you have several, co-located teams that can each have their own Card Wall.
- If your teams are not co-located and you have a need to aggregate data across your teams, be ruthless in your process to find the most light-weight possible approach to gathering that data.
I understand the need for Agile ALM tools. If you’re like me, you’ll view them as a necessary evil. The last thing you want to do is force your teams back into the Chisel-and-Stone era. Even though it’s probably impossible, be unrelenting in your pursuit to make the tools you use “As easy to use as a piece of paper.”
Permalink
11.19.07
Posted in Agile, Iterative Development, Teams at 8:38 pm by Pablosan
So, to the two of you out there still following this blog (okay, maybe there’s three), I’m sorry to leave you hanging for so long – I know you were all waiting with bated breath. I started a new job in October that has been keeping me quite busy, and I’ve started digging into Erlang (you can see some of my progress in using TDD to learn Erlang on CodeNotes. Lame excuses, I know, but it’s all I’ve got.ﾠ
What’s worse, I am purposely going out of order. I intended from the start for the article on TDD to wrap up this series, so today’s installment will cover “The Planning Game.”
ﾠ
We are just about ready to trip the switch on our nuclear furnace. What we need now is a steady supply of fuel! All this talk of gravity and mass is nice, but there has to be something to burn, otherwise our star’s going to be rather dim. The supply of fuel in a star needs to be metered; relatively constant. When this can no longer be maintained the star begins dying, which results in some spectacular visuals, but isn’t great for the star (see white dwarf, neutron star, or supernova for the gory details).
ﾠ
The parallel to Agile teams is clear: while shoving as much work into every day sounds like a good idea, it almost always ends up in burnout. And like our star, the team may end up putting on a spectacular display for a little while (especially the flying sparks as developers and management clash), but the end result is disaster, both for the project and individual members of the team: product quality suffers, morale suffers and, ultimately, our customer suffers. While this has been the norm in our industry for quite some time, it’s time for things to change.
ﾠ
What if we were able to determine what a given team’s sustainable pace was? What if we could know that, for a given set of team members, there was a constant amount of work they could do over a fixed time period, and do it over and over again… no desperate pushes at the end, no threatened mutinies… no burnout? Maybe this sounds Utopian to some, but I believe it is attainable; it just requires planning and discipline.
ﾠ
The Planning game begins with writing User Stories. These Stories define who the user is, what they want to do, and the value they will derive from doing it. Once we’ve exhausted our customer’s imagination and have written as many stories as we can, we have a Backlog. Each story is assigned a business value by the customer (the current trend is to use the MoSCoW Method) and a Technical Risk (usually something creative like “High”, “Medium” and “Low”) by the technical team members. If we now sort our backlog of stories, first by Business Value (high-to-low) and then by Technical Risk (high-to-low), we have a pretty good idea in which order the stories should be developed. Finally, the technical team members assign “Story Points“, at which point we are ready to begin identifying and working on specific Stories. This is the first form of planning and it happens once, at the beginning of the project (yes, User Stories can always be added to the backlog, but I’m trying to keep this from turning into a tome, so bear with me).
ﾠ
The next step happens at the beginning of every Iteration, and Iterations are fixed-time periods lasting anywhere from one week to one month (two or three week Iterations seem to be the sweet-spot for many teams). For instance, if you start with a three week Iteration, all Iterations should be three weeks in length for the duration of the project. Now the technical team members start pulling stories off the top of the prioritized Backlog until they feel they have enough stories to fill the Iteration. We add up the Story Points for those Stories and that becomes our velocity estimate. At the end of the first Iteration, we perform a demo and the customer either signs off on a story and we (the developers) get full credit for the story, or they do not sign off and we get zero credit. We then can add up the Story Points for all of those “done” stories and we have a velocity for our next Iteration.
ﾠ
From Iteration to Iteration, we check our velocity, making minor adjustments as necessary. After the first couple Iterations, we should see our velocity flatten out – we have now found our team’s optimum pace. Having found it, we can maintain that pace indefinitely. The developers are happy, because they are getting work done and seeing solid, high-quality results (and their families even remember who they are from week to week!). The managers are happy because they can easily take the total number of Story Points of all the stories left in the backlog, divide that number by the team’s velocity, and determine an honest, accurate estimate of when the project will be “done.” Most of all, the customer (or stakeholder) is very happy, because they are seeing the highest business value features actually working at the end of each Iteration (because, of course, they are attending the demo and giving us a “yea” or “nay” on whether or not each Story is done).
ﾠ
Story Points isn’t the only way to track progress on an Agile project, but it is the approach I much prefer, mainly because I think it is the approach that best resists the temptation to revert to old metrics (man-hours being the prime offender). There are more details to the planning game (like determing Acceptance Criteria and a Task List for each Story – I’ll leave it as an exercise for the reader to research these), but hopefully this covered the highlights.
ﾠ
With this approach we have a consistent supply of fuel (User Stories), allowing the team to shine bright and long.
ﾠ
How does “The Planning Game” align with the Agile Manifesto? This one is very easy, because it very solidly aligns with all four core values!
Permalink
« Previous entries Next Page » Next Page »
