Monthly Archives: November 2013

4 Estimates & a Gantt Chart – The “Planning Party” Response . . .

Uncategorized

In established political fashion, I must now provide a more sensible “Planning Party response” to the rhetoric espoused by Amos (@adkron) regarding the “appropriate amount of planning” discussed during ThisAgileLife Episode 25 “4 Estimates and a Gantt Chart Ago”.

During the episode, my colleague Amos alleged that 4 months of planning to establish a new blog site (www.theagilefactor.com) was unacceptable, and that much of the planning and consideration that I put into launching the site was unwarranted.  Furthermore I should have been able to bring the site online in less than 4 months, and some may assume from the amateur-style debate rhetoric during Episode 25 that it took me 4 months of focused work to “think about what I wanted to do, then setup WordPress, and finally post something” – let me set the record straight on a few items:

  • Since I have many other obligations and activities going on, working to bring the site online and create the initial content was not my top priority throughout the 4 month period – I focused on it during my extremely limited spare time.  More accurate use of a technique like “Personal Kanban” or “Pomodoro” so as to identify and more carefully track key items (along with the many other items competing for my very limited spare time) may have reduced the time needed to launch the blog as I would have had less total work in progress.  Reducing my work-in-progress and prioritizing completion of the items related to launching the blog would have improved flow.
  • As for Amos’ claim that 4 months from envisioning to delivery was unacceptable – Amos has no solid value data to support this.  Ideally release of capabilities within agile development projects should be prioritized to maximize business value (ideally at the feature, not at the project level); however, in this case, my new blog is something that I’m doing on the side and there wasn’t any significant different in business value (to myself as the business supporting it) if it went online in August or if it showed up in November (like it did).  The key message here is to use business value (at the feature level) to prioritize and determine when capabilities need to be released.
  • All told my brainstorming, concept and goal development, initial writing, and technical setup to launch the website took roughly 12 hours – as mentioned above, this was 12 hours spent in short bursts initially, with longer work sessions to get stuff done as I got closer to a self-imposed deadline to get the site up.
  • The time spent brainstorming and documenting a “vision” amplified by “goals” quantified by “objectives” serves to provide a solid definition of “success” for the blog / site – having a well defined meaning of “success” has served to increase my motivation to work on developing content for the site in my very limited spare time.  I hypothesize that I will be more motivated to sustain the site, since I have documented goals that I want to conquer, and as I complete initial goals, I will define and adopt new goals to ensure that definition of “success” remains relevant.

The key learnings that I hope all can extract from the “4 Estimates and a Gantt Chart” debate are:

#1 – Planning is a needed and valuable activity so as to ensure all involved with a project (or product) have an understood and agreed upon definition of “success” – without a definition of “success” you cannot build a high-quality product.  Regardless of your context or project, how well do you know what “success” is, and more importantly, do you know how each of your day-to-day activities are helping to get you closer to achieving that definition of success.

#2 – Use business value to determine priority for when to stuff (projects/capabilities/features/etc) needs to get done – for personal / side projects use “personal utility” (what value does the project bring you) – if you identify something that has significant value (in either context) prioritize it and get it done.

#3 – Increasing your Work-In-Progress will decrease flow – this has been proven time-and-time again by kanban and lean scientists – techniques like personal kanban or pomodoro can help – they are most effective when you use them to track ALL of your side projects (recall you need to visualize everything going on within the value-stream for maximum benefit).

#4 – Goal setting works so as to make incremental steps towards the definition of “success” – just be careful to ensure that your goals remain relevant, if your objective changes, update your goals, if achieve your goals (which I hope you will) then create new ones – it’s like shampooing your hair: wash / rinse / repeat.

#5 – It doesn’t take 4 months to setup a blog, it should take you less than a day (or perhaps even less based on your success criteria) – if you believe it will bring value of any kind, just go do it – but remember if you are your own product owner, you still need to define what it means for you to be successful.

For those that are intrigued by Tice & Amos debates – next up: “Planguage” – a language all about planning, so as to provide a more precise definition of success.

… qed …

References:
Personal Kanban – http://www.personalkanban.com
Pomodoro – http://en.wikipedia.org/wiki/Pomodoro_Technique
Planguage – http://www.gilb.com/Requirements

Jamming in an “agile rock band” . . .

Uncategorized, ,

Recently I was asked for suggestions on how to go about growing a team of agile coaches within a coaching practice – knowing that sometimes communication is more effective using metaphors, I thought for a moment and came up with something that seemed to “resonate” – what do you think?

My idea was to channel your inner rock star (we all have one) and think about setting up an agile coaching practice as if it was a good “self-managing” rock band.  We all know that a good band needs a lead singer (since that’s who everyone wants to listen to); however, if all you have is a lead singer (a single agile jedi), you’ll have one voice with nothing else to back them up which doesn’t make for a musically diverse experience.  Next round out the band with some instrumentalists (guitar, bass, drums, horns – other coaches) and maybe even some back-up vocalists (newer coaches being mentored by more experienced members of the band).  Realize that each member of the band has a special mix of skills (the instrument/skill they have learned – agile examples: pattern based refactoring, single-team focus, enterprise-focus, executive-focus, CI, TDD, PMP, ITPM, SAFe, story mapping, lean, kanban, metrics, probabilistic forecasting, facilitation, games, etc), but moreover each band member has a common set of knowledge and understanding that enables them to work together – the band members may (or may not) know how to read music, but alas they have a general understanding of how their songs go (agile principles and values), and have an agreed upon goal to perform, so they can put on a performance – in “agile” lexicon, shall we call them T-shaped people.

Now we get to the fun part of the metaphor, which has caused countless “epic rock band blowouts” throughout history for which VH-1 has made countless episodes of “Behind the Music” – who is in charge?  When a rock band performs, it doesn’t have a conductor out in front telling everyone what to do as a symphony orchestra does – the band just seems to figure it out, or rather self-directs.  For a rock band to endure, the band members need to figure out how to effectively “self-govern”, learn how to resolve conflicts and differences of opinion between members that are sure to occur, and work towards an agreed upon goal of giving solid performances with some level of consistency.  None of the band members out rank each other – when it is necessary to make decisions, the band members talk things through and come to consensus leveraging the different viewpoints and experiences within the group.  Good bands also properly leverage the musical skills and abilities of their members to create a unique and defining sound.  If every song had a guitar solo and only a guitar solo with no other band members being featured, the audience might become tired of that, and you can imagine there might be a little bit of conflict back in the dressing room.  Good rock bands know how to feature each of their members when the time is right because they each bring something unique to the band, so as to deliver diverse and dynamic performances.  And let’s not forget that the lead singer can’t sing “All Night Long” (unless they are named Lionel Richie), so there are times when the lead singer leaves the stage (to change wardrobe and visit the roadies) and lets the instrumentalists jam trusting that they won’t send the audience away.

A final role needed to best ensure the band’s success from a business perspective is “a band manager”.  Let’s face it, most rock band performers are focused on how to improve their performances and want to spend their time singing or playing (new songs / new riffs / playing gigs) – if the band has to organize their own tour, that will take time away from their ability to create, innovative, improve and most importantly perform.  Hence the band manager handles the business of booking the tour and working to identify venues and audiences to which the band’s music meets or exceeds audience expectations.  The band manager helps the band maintain a proper balance of time on the road for gigs, and also time for off-the-road rehearsal and composing new music.  Most importantly, the band manager keeps the band in the spotlight where their talents are recognized and have impact, vs. just allowing the band to jam in the garage which although is great fun for the band members, it doesn’t necessarily allow others to benefit from hearing the band’s music.

That’s my idea – anyone wanna jam?

This is “TheAgileFactor”

Uncategorized

I have been long overdue to create some type of an agile-themed blog now, and for which I know a few of my agile-minded colleagues will critique the “Big Enterprise” tactics and self-imposed roadblocks that I worked through to get things up and running.

Getting Started via Analysis & Infrastructure

Right off the back, instead of doing the “simplest thing possible” (which would have been to start using a free blog site), I took a more long-term and strategic approach (which took some time to complete) thinking about branding, a messaging strategy, a target audience, and also setting up an independent site whereby I can easily extract my content (and the comments that I hope all will share) with me, if I need to do so.  The resulting plan was fashioned to supportive of a “free the data” strategy (a common theme in Enterprise Data Management practices), whereby it is considered a best practice to ensure that data within a system can be transferred to another system when needed to safe-guard against system/vendor lock.  The decision to create a site triggered a standard Enterprise Architecture envisioning process to identify possible implementation plans to determine what IT assets in my portfolio I could reuse vs. what capabilities I would need to buy or create so that I could have a blogging / content platform that met my criteria.  Most importantly, I wanted to cater to the user / reader experience, whereby I could control placement and types of ads – or ultimately provide quality content and ideas in an ad-free experience.

But alas, the site is finally up, the first post has been made, and you are reading it – success.  Granted  hope you keep reading . . .

“TheAgileFactor” Concept

TheAgileFactor is intended to provide thought provoking analysis, commentary and guidance based upon topics of interest within the “agile” and “lean” software development communities.  At their core, both “agile” and “lean” are collections of values and principles for which there has been much debate over what they really mean, how to apply them, and for which a market of consulting, training, guidance, frameworks, prescriptive methodologies, quantitative & qualitative metrics (of which we can debate their scientific merit), project management tools and buzzwords has developed.  As part of TheAgileFactor, I will highlight relevant and interesting topics and ideas, while perhaps sharing a few of my own.

The overall intent is to present information and ideas so as to help individuals, teams, organizations and even full blown Enterprises make incremental steps for improvement.  If you have come here looking for the “secret pill for software development success that works for everyone”, you won’t find it because it doesn’t exist (foreshadowing to an upcoming discussion regarding the “proper understanding and use of best practices”); however, I do hope to share practical advice and insightful questions that when applied against your current scenario may help you chart a course forward.  Initially my content focus is centered in the “agile” and “lean” methodology area spanning topics relevant for small teams up to large Enterprises.

If you have invested (or perhaps wasted) any of your time in the last 10+ years watching 24/7 cable news channels (those of you that know me, know that I have), you may know the highest rated cable news program (for 10+ years) is FoxNewsChannel’s O’Reilly Factor.  We can all debate whether or not “the spin really stops” on the O’Reilly factor, but to give credit where credit is due and putting aside political views, Bill and his production team have developed an effective concept / format for promoting awareness, discussion and commentary on much-debated (often complex) political / societal issues which is intended to educate and empower folks to make their own informed decisions.  I hope to do much the same with TheAgileFactor – hence the “Factor” branding.

Initially, I am starting with just written content, but have a “content roadmap” for which the future does include highlighting game & simulation based activities to enable improvement and future media offerings.  As you can see from the initial version here, sharing content and ideas are more important (to me) than style and design.  I will have to consult with my internal Product Owner (me) regarding what is more valuable: more content or pretty pictures & design – of course I value feedback from my customers and end-users otherwise I’d be living true to being an “Evil Architect”.

Other Content Channels

If you would like to broaden your “agile” awareness and learning experience beyond TheAgileFactor (without the need for continued reading), I also contribute to the “ThisAgileLife” Podcast (www.thisagilelife.com – also available on iTunes) using a variety of character / role driven personas – where I envision in future podcasts we may end up discussing Factor content.  I’ll suggest that cross-channel promotion is a key success factor in any digital content/media strategy chartered by a “Center of Excellence”.

In closing, while some may propose, I did not do the “simplest thing possible” to setup a blog site, I will argue that I did wait until the “last responsible moment” by setting up the new site (infrastructure procurement), loading the initial content (that had been pre-drafted and reviewed), and switching over my agile-themed twitter handle over to @TheAgileFactor just minutes before the recording of ThisAgileLife Episode 25 to announce that once again I’m online again.