One of our teams that is undergoing the transformation towards Scrum came across an interesting situation:

• A Sprint, and all its stories have completed all development, testing, acceptance, sign-off, product owner acceptance, etc…
• One Story in the Sprint cannot be released with the Release – because there’s a dependency on the business to have completed end-user training, which the business needs a few more weeks to do.

So how would you handle this?

• Approach 1: Story does not meet the definition of done.
• The training item should have been a task for the story in order to satisfy the goal of potentially shippable.
• Since a dependency/condition to being shippable was not met, it’s not done.
• Thus the Story would be pulled out of the Sprint and moved back into the backlog or into the next Sprint if it still has value and released on the next Release.
• It would cause a dip in points and artificially drop the velocity for that Sprint (all the work by the team was satisfied, there’s no more work to do), but that dip is ok as it points out an issue that prevented value from being delivered.

• Approach 2: Business issues should not affect velocity. 
• The team completed all work needed to create releasable code – the velocity should be recognized.
• If you keep the Story in the Sprint, it would delay the Release… for weeks. Which is the prerogative of the business. However it’s not a few days of delay, it would bump up against the timing of the subsequent release which goes against the mantra of continuous value… value is not created until you release it.
• Alternatively, you could ‘complete’ the story to record the velocity, but create a placeholder in another Sprint to recognize it actually being released. Or replace a faux/filler story just for velocity tracking purposes, and move the real story into the real Sprint/Release that it’ll get released in.

Have you ever cleared your inbox down to zero? It’s the elusive dream we all hope to one day achieve.

One of the challenges we face in this information overloaded work culture of ours is that the sheer volume of information requires constant grooming, categorization, and prioritization.

Consider that your manager is probably getting about 5X-10X more email than you as they’re cc’d on every discussion, decision, and meeting minutes pertaining to the team. Consider that his/her manager is yet another order of magnitude as the scope broadens, and continues to get worse as you go up each management level.

At the executive level you’re going to employ techniques that help you stay on top of what’s going on with the business by prioritizing where your time needs to be spent. Which means they’re going to assess within 2-5 seconds how important an email is and either act on it right away, read and absorb in detail, delete it as non-actionable, or file away for further reading (which they’ll never get around to).

We live in the detail

The problem with people in the technical industry (developers, analysts, project managers), is that our lives revolve around detail. Detailed plans, specifications, unit tests, coding standards, acceptance criteria, etc… it’s all low level detail – and thus our brains are optimized to think at that level.

Executives however operate at a higher, broader, bigger picture perspective. They swoop down to lower level gears when they need to roll up their sleeves, but for the most part they’re focused on where the business is headed.

Follow these tips

Thus the style of communication that works for people who work with low level detail isn’t optimal for executives, so here are some tips to maximize your communication delivery and impact with executives:

• Don’t use narratives

I had always felt that the application could run faster, so I was looking into server performance and by running a number of queries through query analyzer I determined that performance could benefit by adding a number of indices (see initial results below). So I took it upon myself to add a number of non-clustered compound indices that my research has shown to be used in the commonly used join statement, and…

• Narratives are that story telling style of explaining things, where you end up with paragraph after paragraph only to get to the point at the very end.
• They’re time consuming to produce because you’re going to be meticulous considering the audience, and even worse they’ll just quickly scan through it.
• Or if they do want to read the detail, they’ll put it in the read-later category when they have more time, which they rarely do have more time.

• Strategically title your subject
• Don’t use one or two word subject titles, e.g. “performance”. It’s too generic, and not actionable.
• The goal is to try engaging them into reading your email.
• If you have good news, or are trying to pitch an idea that can really help the company – then try to pitch that in the subject line. Many execs deal with a lot of issues, so it’s nice to have an email come in that won’t cause your blood pressure to rise if you read it.
• Tag your subject with the content type, e.g. [idea], [kudos], [proposal], etc…
• E.g.
• [idea] quick solutions to improve application performance
• [proposal] side project to improve performance
• [kudos] Jeff Wilkers landed the Amcom account

• Start with your conclusion/proposal/point first
• The technical/analyst/PM thing to do is build up a case leading to a conclusion. Stating observations, criteria, supporting data, assumptions, etc… Execs don’t have time for this. Get to the point, first.
• Make the rest of your email support that point.
• This opening statement has to be very brief! No more than two sentences. It has to capture the essence, and be written in such a way that it can be absorbed at a glance.

Good news, we’re able to improve application performance by 30%.

The July 2011 issue of the Flash & Flex Developers magazine is now out and available for download. Key articles include:

• Vector Graphics
• Spitesheets and Blitting in ActionScript 3.0
• Adventures in ActionScript – Putting XML to work
• Accelerometer Programming
• What’s new in Catalyst 5.5
• A gentle introduction to dynamic programming
• ActionScript 3.0 Best Practices

You can download the issue for free.

I’ve been working on another post on the theme of vision & goals, and saw a posting on the StrikeFish blog referencing Steve Jobs’ 1997 WWDC closing keynote, and there’s a 5 minute segment at the 4 minute 30 second mark where he talks about focus – and how Apple had suffered from the lack of it.

Context: He’s answering a question regarding a bunch of products Apple killed because although they might have been great technologies, it didn’t fit with where Apple needed to go.

“…Apple suffered for several years from lousy engineering management, I have to say it. And there were people that were going off in 18 different directions, doing arguably interesting things in each one of them.

Good engineers! Lousy management…

And what happened was you look at the farm that’s been created with all these different animals going in different directions, and it doesn’t add up, the total is less than the sum of the parts.

So we had to decide what are the fundamental directions we’re going in, and what makes sense, and what doesn’t. And there were a bunch of things that didn’t. And microcosmically they might have made sense, macrocosmically they made no sense.

And you know the hardest thing is, when you think about focusing right, you think well focusing is about saying yes. No. Focusing is about saying no. Focusing is about saying no. And you got to say no no no. And when you say no, you piss off people…

…and the result of that focus, is going to be really great products, where the total is much greater than the sum of the parts.”

 

Steve Jobs – WWDC 1997 Closing Keynote

VersionOne, one of the juggernauts on the Agile tool industry, is prepping to launch a total overhaul of their user interface. And judging by the teaser images, it looks like a big leap in the right direction.

Last year we at Amcom Technology had evaluated a number of Agile tools, including V1. Our thoughts at the time were that it was incredibly feature laden which would suit a very mature agile shop, and our team was relatively new to Agile and the UI just felt too heavy as we wouldn’t use many of those advanced features (and thus not worth paying for something we wouldn’t use).

What I’m hoping to see in this new UI is a better balance towards those who want to keep the process simple, lightweight, and fast.

New Features

Some key new features they’re touting in the next release:

1. Menu enhancements / faster navigation
2. Readability improvements
3. Whiteboard improvements
4. Switch from pop-ups to modals windows (presumably jQuery style)
5. Better search abilities
6. Modernized/Cleaner UI
7. FireFox 5 & IE9 support
8. HP Quality center 11 integration
9. Electric Cloud Integration
10. Git Integration
11. Hooks to their Data Mart/Analytics for B.I

Release Webinar

If you’re interesting in finding out more they have a few webinars scheduled which you can sign-up from here.

Earlier this year (Jan 2011) there was a lot of hoopla over an article by Scott Ambler on Dr. Dobbs Journal asking Certified ScrumMaster’s to denounce their CSM.

Scott writes:

1. My hope is that all Certified ScrumMasters (CSMs) will denounce the CSM designation if they haven’t done so already. You attended a workshop; it’s nothing to brag about. Also, if you work for an organization that still wants their agile staff to have the CSM designation then you should help ensure that whoever is inflicting that constraint fully understands what it takes to “earn” the CSM.
2. My belief is that the Certified Scrum Trainers (CSTs), and the Scrum Alliance in general, can do a lot better. In reality, you’re the ones who need to denounce the CSM scheme and to declare it over.
3. I’m impressed with the recently formed International Consortium for Agile (ICAgile)and their strategy surrounding agile certification. They appear to be on the right track and my hope is that they find a way to stay on it. Anyone offering agile training services should consider looking into this.
4. Finally, I’ve said it before and I’ll say it again — The Scrum community, and to a lesser extent the agile community in general, has embarrassed itself by tolerating the CSM scheme. Enough is enough. We can do better, and until we do so, our integrity debt continues to grow.

At a surface level this did make sense. During this time I was also putting together a training proposal to help ramp up the various teams at my company who are involved in software development projects, and was very disappointed when I found out how easy it was to get the CSM (two day workshop with a guaranteed pass on the test).

The heart of our training program consisted of onsite training by cPrime that involved all developers, business analysts, and product owners. It was very practical, intense, and hands-on as we worked through the mechanics of the process.

A secondary aspect to that training strategy was to have two people get their CSMs – so that we have least some people on the team that have a deeper understanding and could help lead the transformation. Hence the disappointment when we found out how little is involved to get a CSM.

One of the managers did the CSM ahead of the onsite company training, and I did mine after due to a scheduling conflict. I didn’t think I’d learn much more than what we had learned from the hands-on training. But I found it actually very beneficial.

You need to start somewhere

If you’re getting into Scrum, you need to start somewhere. The CSM training, at least in my case, went into the deep understanding of why we do these various practices, organizational behavior, leading change, and even human psychology. I wish I had taken my laptop because on top of the slides I was writing as fast I could as the trainer dove into various topics, and I ended up with 10 pages of handwritten notes.

Hiring implications

On the hiring side of things, there’s been an explosion of agile related activity. I’m sure there are companies that want to get into agile, and aren’t quite sure how to filter for the top candidates. So filtering for the CSM designation would be an easy first step to try.

However as a manager of a web development team, when hiring you try to gather as many elements/clue/pieces to a person’s profile as possible as it is a big decision to hire someone. The CSM to me doesn’t say they’re an expert, but rather that they at least have that formal theory as a foundation.

Our team had been self learning agile for months, and we felt fairly confident in all the dots, but the CSM training course helped connect the dots together in order to see the big picture – as well as multiple angles of that 3D picture (i.e. seeing things from the various perspectives of different people).

As a hiring manager what I’d also look into, if someone has a CSM, is where they got it from and who the trainer was and research them. Having experienced four agile trainers training our company at different times, we found the trainer/coach makes a huge difference.

At the time, the denouncing-CSM-movement did make sense (to me) on a surface level – if a 5 year old can take the course and get a CSM… it’s worthless. However on a deeper level it serves as a starting point, that you’ve been formally presented with how all the dots fit together, and ideally that you care enough about the cause to begin immersing yourself in the theory.

But it’s only a start – if you were to interview with me, I’d then want to see how you applied that theory, lead change, and helped an organization maximize it’s value in I.T.

Blessing the CSM

The story I heard was that when the Scrum Alliance was initially formed back in the day, they never intended the CSM certification to carry any real importance – it was really just a merit badge to indicate that you cared to learn about this stuff (and Scrum in its fledgeling years didn’t have that many CSMs). But it exploded faster and bigger than what they had ever anticipated, and now that it’s becoming main stream, the validity of the CSM is now under scrutiny.

So yes, with Scrum becoming mainstream, the Scrum Alliance absolutely needs to start working on creditability and making sure the industry doesn’t get tarnished as a result of credential dilution.

Having said that, whomever has a CSM, I hope you don’t denounce it. I hope that you take it seriously as a badge of your conviction towards making customers happy, maximizing value, creating openness and transparency, and working with product owners, and management to create positive work environments (which then yield high producing teams).

I hope that as a CSM you are humble enough to recognize that a CSM is just a start, and that you’ll immerse yourself in the spirit and iterative perfection of its practices.

Adobe today announced the availability for AIR 2.7, which includes the SDK and the associated runtimes.

The focus on recent releases, this release, and (I’d presume) upcoming releases, is continued emphasis on mobile/smartphone/tablet computing. Having recognized the mobile revolution years ago, even prior to the iPhone craze, Adobe continues to make a smart strategic move by combining the ubiquity of Flash and the massive collective talent surrounding the platform.

A core advantage I used to emphasize to those evaluating Flex back in its early years was that it was relatively easy to ensure the same experience/look and feel regardless of OS/Browser combination. Though with advancements in things like jQuery, that argument isn’t as strong.

If you stuck with HTML/CSS/JavaScript – at least you were still sticking with the same languages as you battled trying to get your stuff to look the same on multiple browsers.

Moving onto mobile (assuming you’re making native apps), the multi-browser UI challenges pale in comparison to multi-mobile-OS’s. To start, just dealing with multiple SDKs and programming languages presents a formidable challenge.

Enter Flex & AIR for mobile. As a Flex developer you’re able to create experiences for the big mobile platforms, but  more importantly from a business perspective – your time to market with products and updates can be achieved with fewer resources and faster turn around time simply due to a unified code base.

What’s new in AIR 2.7

iOS:

• Improved iOS performance (up to 4x).
• Improved ease with debugging iOS applications.

Android:

• Support for SD card application installation on Android.

Desktop:

• Media Measurement – analytics regarding how much video is watched, paused, skipped, and other actions
• Acoustic echo cancellation (e.g. for apps that support VOIP abilities and you want to cancel out the sound from the speakers)
• Improved HTML content navigation

Our company HR/Finance Exec had heard about the Agile transformation we’re currently undergoing, and tomorrow we’re doing a company BBQ – so jokingly she asked:

Does agile mean we will release the food as it is cooked?

So I thought I’d take a lighthearted stab at explaining the Agile/Scrum approach if it were to be applied to a BBQ. To keep it digestible to someone who is unfamiliar with s/w development I kept is simple by omitting things like the various meetings (planning, retrospective, and scrum meetings), various roles, that the Sprints are equal length, that you probably wouldn’t map out in detail that many Sprints, etc…

The core theme was the prioritization aspect of it, and that the Product Owner has a goal or desired outcome with each Sprint.

Response:

The team that’s committing to the work agrees to what they’ll deliver in fixed time increments.

Product Vision: For everyone to gather together, socialize while eating BBQ’d burgers and hot dogs, and feel a heighted sense of unity.

Release 1: 06/14/11. Release goal: to eat hot dogs and burgers

Sprint 1: (the day prior) 5pm – 8pm

• Priority 1: Get meat
• Priority 2: Get buns
• Priority 3: Get salad
• Priority 4: Get snacks
• Priority 5: Get drinks

Sprint 2: 11:00am – 11:30am

• Priority 1: Burger Stuff –  Chop up tomatoes, lettuce, onions
• Priority 2: Marinade anything that needs marinating
• Priority 3: Prep salad

Sprint 3: 11:30am – 12:00pm

• Priority 1: Light BBQ
• Priority 2: Begin cooking meat
• Priority 3: Set up tables
• Priority 4: Deploy salad
• Priority 5: Deploy snacks
• Priority 6: Deploy drinks

Sprint 4: 12:00pm – 01:00pm

• Priority 1: Serve food
• Priority 2: Consume food

Sprint 5: 01:00pm – 01:30pm

• Priority 1: Clean up BBQ grill
• Priority 2: Dispose of trash
• Priority 3: Put everything away
• Priority 4: Lie down on floor from feeling too full

Each Sprint focuses on the next bucket of the most valuable priorities, in that if they’re not done, the lower priority items aren’t of much value (e.g. in sprint 1, there’s no point in getting drinks if there’s not going to be any meat because that’s a stated objective in the vision).

The person deciding the priorities is the Product Owner. After each Sprint, they’d be re-prioritizing what goes into the next Sprint based on the throughput data they gathered in the prior Sprint. Anything that didn’t get done, could go back into an unprioritized bucket, or moved into the next Sprint if that’s one of the next most valuable things.

Scenario: At the end of Sprint 2, prepping the salad priority didn’t complete for whatever reason.

Example reprioritization decision 1:

• The Product Owner can decide that we have to keep moving forward as cooked meat directly supports the product vision, not salad. Salad’s a lower nice-to-have priority. Burgers and Hotdogs deliver maximum value so we can’t compromise that user experience.

Example reprioritization decision 2:

• The Product Owner could decide that you can’t have a BBQ without a salad. So going into Sprint 3, the Product Owner may re-prioritize by moving the prepping of the salad into there, and pulling out snacks and drinks (salad = healthy, healthy customers are better for profitability).

The Product Owner is empowered with enough authority to make these priority decisions, however they’d be accountable to the business for the results.

So after the release is complete, the Product Owner would measure if they achieved the heightened sense of unity and use that to strategize on Release #2 (the next company BBQ).

I recently wrote an article for RIARockStars regarding my take on the CF ecosystem and my challenge as a manager to find talented CF developers – along with some our hiring strategies to work around that. I’ll follow up soon with a follow up post more focused on putting together a hiring strategy for managers of Flex and ColdFusion developers.

…read the full article