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
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
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
07.01.09
Posted in Apple, News, Software Development at 2:13 pm by Pablosan
Back in August, 2008 you may remember a series of posts covering my signing up for the iPhone Developer Program. I finally gave up on my updates because… well, the posts would have been redundant: “still nothing.”
While wrapping things up in Buenos Aires, I received an interesting email from Apple. The email contained an iPhone Developer Program Activation Code! The email arrived on 25 June. On 26 June, after completing the online process, I received another email from Apple with the following banner:
Certified iPhone Developer!
Woohoo! I’m certifiable (like I needed Apple’s confirmation to prove THAT)! Now, what did I do with that iPhone app, completed 10 months and 10 days ago…
Permalink
04.09.09
Posted in Journal, News, Software Development at 1:02 pm by Pablosan
I know this news is somewhat old, but I just ran across it last week. I have known that IBM announced a round of aggressive layoffs in North America. What I didn’t know is that they are “offering outgoing workers in the United States and Canada a chance to take an IBM job in India, Nigeria, Russia or other countries.”
It seems that this news has garnered it’s fair share of “simple solutions” and accusations of Naziism (speaking of simple solutions, Steve Yegge has some interesting thoughts).
As is usually the case, I find myself at odds with the “common wisdom.” Maybe I have a unique perspective, but I’m probably just being contrarian. At any rate, I don’t find this offer offensive. From my vantage point, nothing has changed and this is nothing new. Professional careers in IT for U.S. workers have been on the decline for some time now (“some time” being… oh, I don’t know… a DECADE or more). Moreover, sending U.S. citizens off to foreign countries to earn their keep has been going on for far longer than the aforementioned decline. The only difference I see is that IBM has chosen to be open and honest about the practice. I applaud them for their candidness.
I like the idea of having one more option. It doesn’t sound to me like anyone is being forced to accept a position overseas, and I’m sure there are some who would jump at the chance to spend a little time abroad at the company’s expense. Why not look at it as an opportunity, with pros and cons, just like every other opportunity? I have friends at my current company who have quite enjoyed having their relocation costs covered and are now living an extravagant lifestyle by our standards, albeit on another continent.
Is it ideal? No, it’s life. Make the best of it.
Permalink
01.30.09
Posted in Agile, Journal, Software Development, Travel at 12:49 pm by Pablosan
The idea that constraints are constructive is not a novel one, by far. Study any of the arts and you quickly learn how artists use constraints to inform their creativity: jazz idioms, a painter’s choice of color palette or medium (oils, acrylics, water colors, etc.), an architect’s choice of materials, textures and shapes. Limiting possibilities is an essential part of the creative process. A Blues drummer once told me “It’s not just what you play that matters: knowing what not to play is what separates a good musician from a great one.” Lately, I’ve noticed this principle in three places that have surprised me.
Twitter
I’ve been using Twitter for about six months now. 140 characters of text doesn’t leave a lot of room to get your point across. It’s amazing the amount of clarity focusing on brevity can bring!
iPhone
It is no coincidence that the day I started using Twitter closely coincides with the release of the 3G iPhone. I finally had a mobile device that was actually usable for more than just phone calls. Many of my friends told me they were spending much less time on their computers because they could do so much on their iPhone. I did not expect that to be the case for me… and I was wrong. One might describe the iPhone as a laptop with a few, rather severe constraints: like the lack of a real keyboard, for instance. Much like the result of Twitter’s 140 character constraint, I find the lack of a real keyboard encourages me to keep my email responses small and poignant (hopefully you’re not wishing I would have written this blog entry on my iPhone!).
Travel & Packing
For my latest business trip, I decided that everything I needed for the trip had to fit in my backpack. I was doing my best to follow Andrew Hyde’s excellent example. I was very pleased with the added freedom packing lightly provided.
Over the past year I have been challenging software development teams and product management teams alike to start asking “what can we live without?” What features, enhancements, processes are not needed? What existing features can we live without? What’s not pulling it’s own weight? What is the customer ignoring or, worse yet, what are they working around.
Your product should not be like the ever-expanding universe. Learn how to use constraints to keep projects and products small and poignant! What you exclude from products and projects is as important as what you add.
Permalink
« Previous entries Next Page » Next Page »
