Pastor Ayo Dada (aka Uncle Shafe!)

 Pastor Ayo Dada son of Pastor Philip Dada, Senior brother of my Aunty Titi, Junior brother of Baba Ijo Sola Dada, Rev. Olu Dada and Mommy Akure,

My father was one of the greatest men I ever knew but you were my other role model.  From as far as I can remember I wanted to be like you. You were smart, vibrant, hard working, ambitious and most of all you were a great dancer.  I wanted to be all of these things when I grow up, I wanted to be like you heck I wanted to have a beautiful girlfriend like you had and marry a woman as fun, loving and giving as Aunty Iyabo. I’m still trying to be a great dancer like you I need more work there. J

My first plane ride was because of you, I got to see Zaria and experience the cold harmattan weather of the north, drank fura and maishanu.

You loved me before I knew to love you. You told me stories about the selfless sacrifices my dad made for you and the rest of his siblings. Your story about pretending to be a haunted spirit and scaring a village from their water source was the best!! J

When Popsie passed away you showed us the love and respect that you had for the man and honored him in your relationship with us.

Shafe!!! That’s my mother calling, a name we all adopted. You will never be forgotten. Adieu! And welcome, Heaven is about to be entertained with some good music and dancing! Go ahead Uncle Shafe show them how it’s done.

May your soul rest in peace! I am proud to have known you and to call you Uncle Shafe!!

Your nephew

Kayode

Agile Release Planning

Agile release planning helps team to answer the following questions about their project:

• What can customers expect?
• About when will they get it?
• And how much will it cost?

Done well it is useful tool for teams to define release themes/goals/objectives and explore early release opportunities so that they can get customer feedback and/or potentially earlier return on investments. It is also a great opportunity to do some team building especially with a distributed team. When I facilitate this event I typically include some fun team games I learnt from Simon McPherson(@SIMONMACPHERS0N and http://gamessimonplays.com/).

 

This post reflects useful tips I've gathered from facilitating these events with small (< 8) and large teams (> 50) across multiple industries (Software, Healthcare, Telecoms and Finance). It also reflects the wisdom I got from co-facilitating this event with many great individuals:

 

Plan for the Release Planning Event

• Identify a facilitator (Scrum Master or Agile Coach) for the event
• Have a Product Vision, High level goals and Objectives
• Ensure the product backlog is prioritized and relatively stable
• Check that the Team velocity is relatively stable (after 3 - 4 Iterations or so)
• Understand the key drivers for your project i.e. Trade-off matrix
• Note key event and their dates they may impact your project

 

Invite the right People

• Product Owner
• Scrum Master
• Team Members
• Domain Experts
• Architects
• Others (anyone that can help ensure your plan is a good one)

Have an Agenda for the meeting

• Establish working agreement for the event
• Product Owner presents product vision and roadmap
• Product Owner presents the project’s trade-off matrix
• Product Owner presents the prioritized product backlog
• Team asks questions to understand user stories
• Team estimates user stories at a high level (Affinity Estimating or similar technique)
• Team should split User Stories that are too large to complete within an Iteration or add new discovered ones
• Determine your MVPs/MMFs/MMFSs (Story mapping is a good technique to lay out what story set is needed to deliver value)
• Team reviews key dates, milestones and Sprint calendar
• Team discusses dependencies
• Team discusses plan risks and/or issues
• Team finalizes release plan showing what will be worked on in each Sprint and future release candidates
• Record any key decisions, assumptions, dependencies, risks and/or issues
• Team commits to Release Plan
• Product Owner communicates plan to Stakeholders/Management
• Meeting Retrospective

 Watch out for these

• Product Owner not the decision maker for your project? It will be difficult to negotiate your trade-off matrix, accetance criteria, MVPs if your PO isn't making the decisions.
• Diving into too much detail and complex design discussions: Save yourself! You will have at least two more opportunities to review each product backlog item before the team works on it (1) Backlog Grooming meeting and (2) Sprint Planning meeting

Communicate your plan to Management/Stakeholders

Your communication should include:

• Release plan: What are your deliverying and by when. Include Release candidates (MVPs)  you've identified.
• Key assumptions: State any assumptions your are making in coming up with your plan
• Dependencies list: Resolve dependencies before the team pulls stories into their Sprint backlog.
• Risks and issues: Note mitigation strategies and any adjustments to release plan

Don't let it get Stale 

• Review/Track/Update your release plan at the begining of every Sprint. The plan is only useful if you keep it updated and make adjustments based on new information from executing your Sprints

 Reference

1. Version One’s Agile Checklist.

 

Agile Will Fail Because . . .

I was at the Agile 2013 conference in Nashville, Tennessee, in August and had the opportunity to participate in the Scrum Alliance-sponsored Coaches Clinic. Two of the volunteers at the clinic, Dhaval Panchal (www.dhavalpanchal.com/) and Michael Vizdos (www.VizdosEnterprises.com), put up a poster board with a simple statement: "Agile will fail at my company because . . ." Dhaval had created similar board at the Scrum Alliance Global Gathering in Atlanta (2012) as a way to provide a venting box for conference attendees and to raise awareness about topics that can be addressed at the Coaches Clinic.

I wish I had thought of this at the time: It would have been interesting to have had a board opposite this one with the statement "Agile is succeeding at my company because . . ."

Anyway, about 50 people scribbled on the board, and I took pictures and transcribed the scribbles, hoping to get ideas for blogs and articles. Well, I have one for you now, telling the story of what the scribbles revealed to me. The groupings of items fell into the following categories (the complete list is below):

• Lack of awareness/No need for change
• Lack of support/Desire to change
• Agile is misunderstood/Ability to change

What struck me was how this aligns with the Prosci^® ADKAR^® model (http://www.prosci.com/adkar-model/overview-3/):

• Awareness of the need for change
• Desire to participate and support the change
• Knowledge of how to change
• Ability to implement required skills and behaviors
• Reinforcement to sustain the change

Using the ADKAR model, you can see that the Knowledge of how to change did not come up in the poster board notes. This is as expected, giving the volume of information, training, conferences, and consulting companies out there preaching Agile values and offering to help people acquire the necessary knowledge of how to change.

No notes made it into in the Reinforcement category. It's not clear whether this means Agile fails before companies get to reinforce its values, or that when Agile values are reinforced there is a greater chance that it will be successful.

Transcription of the notes from Agile 2013, Nashville, Tennessee:
Lack of awareness/No need for change

• We think we are "Agile."
• We have not explained the why.
• What we do already works!?
• We only fund capital projects.
• It does not support secure software (ISO 2700 or Code Analyzers).
• Because my customer prefers Waterfall.
• We are different. Just like everyone else who has done it.
• We can't show the value.
• No buy-in from the business.

Lack of support/Desire to change

• We don't want it badly enough.
• They don't want to change and no Lean leadership.
• Clashes with current (complex) business model.
• Jim.
• Insufficient support from leadership.
• Because the CEO manages with fear and intimidation.
• Strong and growing PMO. The traditional structure is being instituted.
• Duplicitous product owners (ScrumMasters).
• We lose trust in each other.
• Because of our culture.
• My leadership team no longer believes in it.
• They think it is only a development methodology.
• Only focused on changes in development teams; not looking at whole value stream (product ideation and management).
• Our egos are bigger and more important than the company goals.
• Of me.
• Because I'm writing on this wall and I think it will so it will.
• My manager has to assign work to the team.
• Adoption is done because of convenience not because of conviction.
• The company wears "Agile" as a label and yet does nothing to remove the bureaucracy and obstacles team face daily while trying to implement change.
• They won't change ("They?" Maybe this is contributing to the problem).

Agile is misunderstood/Ability to change

• Not everyone on our team understands it.
• The concept of being dedicated to one task (story) at a time is not supported!
• Because Agile is a state of being, not doing. Agile is grossly misunderstood. SADLY!
• It is counterintuitive & hard to practice.
• Because failure is good for learning.
• Too many silos with their own goals that aren't the customer's goals.
• Different parts of the biz use different types of Agile.
• Too much focus on the mechanics of the process, not enough on the motivation/passion behind it.
• Because Agile is not the goal. Agile is simply a means to an end.
• Re-org will set us back to the beginning again and again.

My overall read from the notes is this: It is not enough to simply espouse the wonders of Agile, it is not enough that we educate people on Agile practices, it is not enough to quibble over which Agile flavor is best for you. If you don't treat Agile adoption as an organizational-change management challenge, and manage it as such, there is a good chance that it will fail.

Cloud Computing Google World View Notes

Presenter:
Mike Repass, Product Manager (reminder: Product Managers at Google are technical folks and not marketing folks like other companies, his words not mine, ex-MSFT dude).
You can follow him on http://twitter.com/mdrcode/

Websites:
http://appengine.google.com/
http://code.google.com/appengine/

Highlights
- Cloud computing based platform is in the managed platforms (non-machine) space, more on this later.
- Free Trial for ever.
- Buddy Poke ( http://www.buddypoke.com/ ) and www.whitehouse.gov/OpenForQuestions are examples of site using it
- Billing and Quota just released (This pay as you go is the secret source of cloud computing in my opinion )
- Support only for Python runtime 2.5 modified no other language is supported
- Uses same Google infrastructure
- Data export tool available in case you don’t like the service and want to take your stuff somewhere else (remember: Google does no evil!)
- Approach is very Developer centric, which is great! No assemblies required

Lowlights
- No IDE for Development, SDK + Documentation can be downloaded from the site. Last company that did this almost lost the runtime war somewhat at least, Java SDK released with no IDE back in the day. Everyday Developers (not hardcore, command line switching guys/gals love IDE, it’s a productivity issue.
- Support for only one language
- No message queuing support, so your website cannot do transactions, at least none that is meaningful
- No support for large files, this is on the roadmap though, there is a limit to the size of document you can upload.

Cloud Computing: Amazon Web Services (AWS)

Early March I attended a presentation on Amazon’s Web Services (AWS), it was the second in a series of presentations on cloud computing put together by the washing technology industry association. The first event in the series provided an overview of cloud computing, while subsequent events focused on vendor specific take/implementations.

AWS combines various aspects of cloud computing, the EC2 service is largely a virtual environment, S3 provides storage while Cloud Front, SimpleDB and Simple Queue Service are web services that have been used by Amazon for its own internal development now made available to outside developers. Mechanical Turk, is an interesting addition to the AWS suite, provides people in the cloud that can get pretty much any tasks completed for you from research restaurants in your area, to development (coding). According to Andy Jassy (VP, Web Services), there are about four hundred thousand developers using AWS today and the presentation included customer evidence from two companies leveraging AWS and on-premises deployment. I don’t recall the break-down of the figure though and I wonder if Mechanical Turks coders are part of this number.

Also interesting is a comment by Andy that only about 20% of computing resources deployed by companies is utilized, not sure where this number came from but I can understand the low utilization figures considering the fact that most capacity planning exercise basically consider the maximum load expected plus a growth rate factor in determining what resource needs to be provided to accomplish the desired performance metric. This maximum load however may only ever be reached a few times during the day but the resources have to be available throughout the day since computing resource could not be acquired on-demand for this peak period. Hence the value of cloud computing, pay for only what you use.

With the ability to pay per use (this is the gem on cloud computing) AWS offers potential huge saving when compared to the on-premises model. In addition, it offers the ability to scale as necessary by simply requesting more resource as your application’s user base grows. In addition, a number of vendors e.g. IBM now allow customer to take existing license and use it in the cloud or purchase per usage licenses for their products in the cloud. EC2 now offers Windows on a pay per use basis.

Tood Fasullo of SmartSheet (S3/CloudFront/MT) and Mike Harrington of Picnik (EC2) both discussed their use of AWS. They both combine AWS with on-premises/hosted deployments.

There were no real surprises at this event mainly because I’ve followed AWS development since Wall Street dogged Jeff Bezos for spending too much money on it.

MLK Day 2009 Thoughts

Today is MLK day, I spent it catching up on my African American history, overdosing on the Inauguration broadcasts, the rhetoric on the significance of the inauguration of the first Black President and something about what Michelle Obama will wear to inaugural balls. In all of these, I kept searching for why is this really significant to blacks in America, why do blacks talk about this inauguration as the realization of the dream? Why does the rest of the world care about an historic moment in America? The latter question is somewhat easier to answer (I said somewhat), "I have a dream" is a well recognized phrase across the world as is its author and I want to believe that for years the world watched to see if the dream will ever be realized in America and by electing the first black president the dream is fulfilled and the American dream lives on.

The former question was a little harder to crack. Understanding segregation and recognizing racism is tough if you haven't lived through. Yes I have seen the pictures and I've spoken to enough black people who have told me the stories of the time, eventually my answer came from the following text in Dr. King's "Letter from Birmingham Jail" in response to a statement issued by the Alabama Clergymen.

"When you are humiliated day in and day out by nagging signs reading "white" and "colored"; ..... when your first name becomes "nigger", your middle name becomes "boy" .......... when you are forever fighting a degenerating sense of "nobodiness"--then you will understand why we find it difficult to wait."

It's true the signs have come down, the N-word became politically incorrect (unless of course you are black then it’s ok) and Lyndon Johnson signed The Voting Rights Acts but that degenerating sense of “nobodiness” lingered on for the most part until November 4th, 2008.

On January 20th, 2009 blacks in America will undoubtedly be celebrating the historic event of the inauguration of the first black president with a reassured sense of being somebody.

Happy MLK Day!!!

The Longest Night

One Easter Sunday, the Alaska Ranger—a fishing boat out of Dutch Harbor—went down in the Bering Sea, 6,000 feet deep and thirty-two degrees cold. Forty-seven people were on board, and nearly half of them would spend hours floating alone in the darkness, in water so frigid it can kill a man in minutes. Forty-two of them would be rescued. Here’s how http://men.style.com/gq/features/landing?id=content_7619

I was drawn to Sean Flynn's incredible story of rescue in the Bering Sea partly because my company shares an office building with a fishing company and the Alaska Ranger is owned by a fishing company based in Seattle. Sean Flynn did a great job in this article, I was reading the story on a plane ride back to Seattle but Sean's style put me smack in the middle of the action, I felt the cold and darkness experienced by the survivors and the adrenaline rush experienced by the coast guard.

I'm a firm believer that if you enable smart people by providing clear goals and guidelines they will accomplish exceptional results and this story exemplified that. The decisions made by the coast guard personnels on the scene were sometimes against standard procedure but these decisions were critical in increasing the odds of survival of the distressed crewmen. There is definitely a place for not following the rule if you understand the ultimately objective which in this case was to save life.