02.23.10
Posted in Apple, Journal, News at 9:29 pm by Pablosan
I’ll get back to Agile Blind Spots in my next post, but I have discovered a great app and piece of hardware that has turned my iPhone into an art easel.
Brushes is an iPhone app that was highlighted during the introduction of the iPad a few weeks ago. One of my hobbies is Graphic Arts and I have often bemoaned the fact that I can’t find more time to spend on it. I even carry around a Wacom tablet… that rarely gets used: partially because there is a (very little) bit of setup required, but mostly because I’ve never been able to get comfortable with drawing in one place (on the tablet) while watching someplace else (the monitor) to see how it looks.
Once the iPad rumors hit a fevered pitch, my first thought was that it would make a great graphic arts platform. When Apple highlighted Brushes during the iPad unveiling I decided to purchase it for my iPhone. I played with it a little, but found the lack of accuracy due to using a fingertip somewhat off-putting. I’ve put in many hundreds of hours sketching with a pencil or pen so that approach is completely natural to me. I thought using my fingertip would be close enough to be satisfying, but… well, it isn’t. I really need a writing utensil in my hand.
While I’m really excited about the iPad, it’s looking like it will not ship with a stylus and this is a bit of a disappointment. Enter Ten One Design and the Pogo Sketch, a stylus that works with the iPhone, with newer Macbook trackpads and the iPad (well, once they’re released anyway… Hurry up Apple!!!).
But wait, there’s more! The pièce de résistance: due to a built in Web server that allows you to transfer drawings from Brushes on your iPhone to your Mac and a companion Mac app, Brushes Viewer, you can get a high resolution version of your small-screen artwork. Since the iPhone app actually records your strokes, it can replay those strokes at a higher resolution. Not only that, you can actually watch yourself create your masterpiece and save it off as a Quicktime movie! The max resolution for a static image is 1920 x 2880 and it looks incredible. While I wasn’t happy with the results I was getting using my fingertip, I’m very happy with the results using a stylus. Here is a medium quality (960 x 640) version of my first attempt using a stylus (click on the image to see it full size):
Paul Nelson, 15 February, 2010
The combination of the Brushes app, the Pogo Sketch stylus and Brushes Viewer means I can carry an art studio in my pocket… well, close enough.
I can’t wait to play with Brushes and the Pogo Sketch on an iPad! Oh… and look for a nice tie-in with my Agile Blind Spots series of articles soon!
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.29.10
Posted in Apple, Journal at 3:14 pm by Pablosan
I’ve purposely refrained from reading too much about the release of the iPad. In all likelihood these points have already been made elsewhere, but this is my view of Apple’s new toy.
I’ll start with the patently obvious (pun intended): exactly like their introduction of the iPod, and exactly like their follow-on introduction of the iPhone, the iPad’s primary raison d’être is to provide yet another portal to content. Steve Jobs brazenly admitted as much in Wednesday’s product announcement, citing a couple of facts:
- Apple has 175 million consumer credit card numbers attached to iTunes accounts.
- Customers have downloaded 3 billion apps for their iPhones and iPod Touches
That’s just applications! What about music and videos?
- As of a year ago (Phil Schiller’s Macworld keynote) iTunes customers had purchased 6 billion songs.
- Over a year and a half ago, customers were purchasing 50,000 videos per day on iTunes. Assuming that hasn’t changed (and the daily rate is likely much higher today), that would be over 18 million video downloads per year.
Interestingly, as the iPhone and iPod Touch opened up new content sales for Apple in the form of videos, the iPad also adds ebooks. So Apple wants you, me – all of us – to purchase our content from them. The devices are simply the conduit. Granted, the folks at Apple are software and hardware artisans, so using their devices to consume all that content is a joy in itself. But I think Apple figured out a while ago that hardware will continue to be marginalized and that “content is king.”
So enough stating the obvious. I’ve heard a few people (geeks, mostly) ask questions that basically boil down to “So what? Who cares?” I have an iPhone. I have a Macbook Pro. The last thing I want to do is lug around a third device that doesn’t give me anything new!
I’ve also heard it stated that the iPad is a let-down because it’s evolutionary, not revolutionary. I disagree with these sentiments. I think the iPad is revolutionary and I think we, as geeks, need to sit up and take notice. It has been a very long time coming, but the way we interact with computers is finally becoming a bit more… human. Lately, there has been a lot of buzz in the IT world about User Experience, stating that it has been a second-class citizen for far too long. We are striving to simplify interfaces and improve user experience. Yet we still expect every computer user to be proficient with a keyboard and a mouse, to understand hierarchical menu systems, keyboard shortcuts, archaic command line incantations, etc.
Years ago, I had an idea for a computing device. The impetus for my idea was the simple thought that “a computer should be as easy to use as a piece of paper.” The iPad is not that device, but it is much closer than a device that uses a keyboard and a pointing device. What is more natural than pointing at something with your finger? The iPad is revolutionary by being a full-scale computing device that we interact with very naturally; directly. It eliminates a layer of abstraction at the most fragile, yet crucial part of any system: user input. This is a Good Thing, and I can’t wait to see where this latest step in improving user experience leads us!
So I, for one, will be lugging around three devices… at least for a while.
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 »
