Thursday, February 12, 2015
Saturday, October 26, 2013
- What can customers expect?
- About when will they get it?
- And how much will it cost?
- 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
- Product Owner
- Scrum Master
- Team Members
- Domain Experts
- Others (anyone that can help ensure your plan is a good one)
- 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
- 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
- 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
- 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
Thursday, September 26, 2013
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
- 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
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.
- We don't want it badly enough.
- They don't want to change and no Lean leadership.
- Clashes with current (complex) business model.
- 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).
- 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.
Tuesday, April 14, 2009
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/
- 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
- 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.
Tuesday, March 31, 2009
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.
Monday, January 19, 2009
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!!!
Sunday, January 4, 2009
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.