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
02.18.10
Posted in Agile, Iterative Development, Software Development at 6:57 pm by Pablosan
In my previous post I went out on a limb and claimed that, while Agile places a high level of importance on “Business Value”, too many Agile projects seem to miss the mark when it comes to providing real value in the real world. To be fair, Agile methodologies have primarily focused on delivering working software in an iterative fashion, which is only a small portion of the overall process of seeing a gleam in one’s eye become a tangible, usable product.
Fortunately Agile is about executing, learning and adapting and I am beginning to see a push in two directions: both into the activities that lead up to the project’s visioning exercise and into assessing the value the project is providing in the real world.
One of the things that I really appreciate about Agile is the vetting process that helps a team prioritize the work in the backlog based on Business Value. This insures that those features having the highest potential for the most business value are completed first. This is highly effective in the confines of a given project. However, nothing in this process addresses: 1. how this project fits into the overall vision of the organization, 2. how the value of this project compares to other projects in the organization, and 3. A sense of whether or not the actual user will find the product useful.
In all fairness, it can be argued that these concerns fall outside the responsibilities of the project. But I submit that if an Agile team successfully delivers a feature set that does not fit in the overall vision of the organization, or is of less value than other projects that were passed over in favor of this project, or fail to prove useful to the end user, the project is a failure, ergo Agile has failed.
That may seem harsh, but I believe it is accurate. In order for Agile to continue to thrive, it must push forward into the process (or lack thereof) that precedes kicking off the project. Fortunately this is a fairly simple concept. An organization can apply the same vetting process used within the project to the process of selecting which projects actually get worked on and in which order. It is not hard to envision creating a prioritized queue of products or feature sets at a level above the actual project execution.
It is not enough to successfully deliver a project if the project itself is improperly positioned. Agile needs to push upstream. We need to start asking the tough questions:
- How does a given project support the overall vision of the organization?
- Where does a given project fall in the overall prioritization for all work on deck?
- What research have we done to provide a reasonable level of confidence that a given project will provide real value in the real world?
If you are OCD… er, detail-oriented like me, you may have noticed that I have only addressed two of the three concerns I listed earlier. I’ll save the third one for next time. In the meantime, how do you envision your company pushing the Agile values upstream in an effort to provide the right thing to the right people at the right time?
Permalink
Posted in Agile, Iterative Development, Software Development at 5:48 pm by Pablosan
I’m feeling the need to state up front that:
- I am not trying to incite a religious war over the merits of Agile or any given Agile methodology
- I think Agile has been a significant positive force in the IT Industry, driving a focus on continual improvement, quality, incremental delivery and, overall, bringing back a fair amount of science to computer science.
Let me state my assumptions: first, Agile is IT process-centric because it was created by software engineers. The reason the term was coined and the movement birthed is because we in IT were tired of a heavy-weight process that had a track record of setting us up for failure. I am extremely grateful that a group self-organized back in late 2001 to stop the insanity and blaze a trail in a new direction. As is often the case, that which gives us our strength is also our downfall.
My second assumption is that the direction of a project and the details of a process should be driven by providing real value in the real world. I’m sure that some of you are already jumping ahead of me and planning my lynching, because I obviously have missed the point that Agile is all about “Business Value.” Hopefully you’ll give me time to explain. While business value is firmly espoused in principle, I’m not convinced that the concept is well understood and, therefore, misses the mark in execution (this statement is based on direct observation of dozens of teams who are doing their best to follow Agile principles and continually improve). The reason for this is straightforward: Agile is being driven by IT. Our focus is on “working software.” Yes, “working” should include the concept of providing real value in the real world, but does it? How do we know? Are we utilizing objective measurements to show how real customers are using the product in the real world? Or are we satisfied validating this through the tacit approval of a Product Owner?
More importantly, is anyone stopping to ask these questions before we get started? I am continually surprised by how many software projects are given the green light or continue to live without anyone asking the hard questions: how will we justify the significant expense incurred to create and maintain this? How many users will actually use it? Will those who we expect to use this find it valuable? What problems will it solve? What problems will it create? How can we know the answers to these questions before we have a product for someone to use? It strikes me that there are very few products who could get away with making it to production without answering these questions. I think the days of software products getting away with it are numbered.
Let me pose a simple question: how many non-IT business professionals can you list who are making a significant contribution to the Agile movement? How many Product Managers? Product Marketers? Corporate Executives? I know my circle is small, but I can’t think of any. It seems to me that if we were truly engaging “the Business side of the house” that they would eventually have a significant presence as speakers at conferences, authors of books on Agile and the like. Yet the Agile landscape is still dominated by geeks.
This is not to say that Agile has failed, but I do think Agile can only go so far: it can only solve certain problems in its current state. Agile has performed splendidly, moving us away from a draconian focus on process, but I am not convinced it can take us all the way to where we need to be: focused on providing real value in the real world. IT cannot lead us there. We desperately need someone without our blind spots to show us the way.
Fortunately, many in Agile circles are already wrestling with this issue and I intend to delve deeper into some proposed solutions in my next article.
So what do you think? Am I completely off-base? Are we already there and I’m just late to the game? As always, your comments are welcome!
Permalink
01.11.10
Posted in Agile, Go, Software Development at 2:04 pm by Pablosan
I recently ran across Kent Beck’s blog post, Valuing Ambiquity. In it he uses the game of Go as an excellent analogy for dealing with ambiguity in software development.
I have been a casual Go player for about two years now, ever since being introduced to the game by a friend and former teammate. Around that same timeframe I read somewhere online that all software developers should learn the game of Go (sidenote: if there was ever a case for Semantic Web, it is Go. Googling “Go” is… pointless).
I’ve written about Go before, and looking back on my approach to Go so far (I am probably rated around 20 kyu, which is a rank beginner) gives me plenty of object lessons.
One such lesson is looking at the game as an emerging design. I have no idea what the end state of a game of Go will be. The way I currently approach the game is to quickly survey the entire board with a bias for the area in which my opponent just played, in order to narrow my focus to a few strategic moves. This usually leads me to a smaller section of the board, where I will play out a series of moves in my head to determine which of my possible moves seems the most valuable (value being defined as the right balance between potential gains and potential losses).
I have found the same approach useful in improving the design of legacy code. In dealing with very large codebases (over 500K lines of code), I find it impossible to determine what the end-result of design improvements should be. However, I can look at small parts of the system and see small ways in which the design could be improved. Many times I am looking in a certain section of code because a search for the root-cause of a defect has led me there (my opponent’s last move?). Writing Unit Tests allows me to explore the problem space and find the best course of action. All of this leads to incrementally improving design, which in turn increases value.
The hard part, both in the game of Go and in software development (as Kent Beck clearly articulates), is dealing with ambiguity. I cannot lose sight of the big picture: staying focused on a small subset of the overall problem space almost certainly results in failure. Yet allowing the insurmountable complexity of the big picture to paralyze me is as detrimental as losing sight of it.
Like so many things in life, it’s all about balance: balancing potential gains and potential losses as well as balancing focus on the big picture and focus on the details.
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
09.15.09
Posted in Agile, Journal, News at 9:04 pm by Pablosan
Well, there you have it. I made my choice! I’m hanging out my shingle, striking out on my own, etc. People keep asking me if I’m excited. Terrified is, I think, more appropriate.
But I am not completely alone. I’ll be working very closely with these guys. Just to give you an idea of how hip this group is, take a look at their office! Yep, it’s a boat and, yes, they have a nice view of Lake Erie and the Cleveland skyline.
This new opportunity will give me the privilege of continuing to pursue my passion: helping software development teams have a lot of fun making real progress on real projects.
It seems that the current Agile Hype is around Kanban, so I thought I’d tie that in as well. I am both impressed with and concerned about kanban for software development, a new-ish methodology taking ideas from Lean and from the Toyota Production System (TPS). There are many great ideas in this newest evolutionary step in Agile: a focus on quality, limiting work-in-process, balancing demand against throughput, effective prioritization, pull don’t push, continual improvement, eliminating waste, and many more. All of these are powerful concepts (David Anderson gave an excellent talk on kanban, which you can find here).
Why the concern? Well, it seems that certain other Agile methodologies have ended up being more about creating marketable intellectual property than solving real-world problems. And I think that’s an easy trap to fall into. Marketing an idea is important to it’s survival, and that is going to create tension. As long as those behind the Kanban approach stay focused on solving real-world problems, we’ll be fine, but they will have to fight against the urge to over-market their ideas.
I hope they succeed, because I think this latest incarnation of Agile is a very good thing! And I’m looking forward to proving that out over the next several months while watching kanban for software development continually improve!
Permalink
09.13.09
Posted in Agile, Journal at 2:32 pm by Pablosan
I have been faced with a minor dilemma. Having been presented with an opportunity to venture off on my own as an independent consultant, I now have to decide between staying in my current position or accepting this new challenge.
It has proven to be a particularly thorny problem. My current contract position has given me an opportunity to make a positive impact that has been noticed all the way up to the CIO. In a company of roughly 10,000 employees, this fact in itself plays a significant role in my selection process. Add to this that I am working under the best manager I’ve ever had doing things that I really enjoy… well, why leave?!
The consulting opportunity, on the other hand, will give me fresh opportunities to dig into new challenges with a group of consultants that I am confident would push the envelope further than I would do on my own. In fact, this opportunity reminds me of the part of Chad Fowler’s book where he quotes Pat Metheny’s advice for young musicians: “always be the worst guy in every band you’re in.” This gig definitely qualifies.
After several days of wracking my brain trying to make a decision, I was reminded of another piece of advice I recently read in Gerald Weinberg’s book, The Secrets of Consulting
. In the book he uses The Principle of Least Regret, specifically in regards to setting your consulting rate, but I think it applies in my current situation as well.
The idea is simple: given a set of options that are roughly equivalent, choose the option that you believe will leave you with the least regret. Another way to consider it is, choose the option which you would most regret not taking.
Having used this principle recently, I am convinced it could be useful in many contexts. For instance, it could help in backlog prioritization on an Agile project. However, I also think that this particular principle will not work all of the time. In other words, it is a great tool to have in your toolbox, but don’t expect to use it in every situation.
So which did I choose? All in good time. There are still i’s to be dotted and t’s to be crossed, so stay tuned!
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
« Previous entries Next Page » Next Page »
