Agile Open Day at Red Hat Beijing Office

On 17th Sept, during Agile Open Day at Red Hat's Beijing office, I had the opportunity to train, interact, connect and learn with teams.

Although the nature of the event meant to be open but we tried to keep our focus on following topics:

1. Introduction to Agile, Overview of Agile Manifesto and Framework
2. Agile Methods e.g. Getting Agile with Scrum
3. Agile Estimation
4. Story Writing
5. Agile Planning e.g. Vision, Roadmap, Release, Sprint, Daily
6. Agile Games
7. Agile Project Monitoring
8. Agile Adoption
9. Agile Quality
10. Best Practices

The event had remarkable turn around of 50+ people, who took time off to be there but I must admit I was mostly impressed with the audience for following aspects:

1. Variety and Background,people from different age groups and teams turned up e.g. Kernel, Product Engineering, QA, Project Managers, Leads, IT, System Admins  etc.
2. Remarkable enthusiasm
3. Being involved
4. Willingness to learn and share from their own experience.

We make use of Agile Games to ensure whatever I covered during presentations can be reflected by getting everyone involved. This has really paid off well as everyone held their own perspective but at the same time everyone performed as a team and had fun at the same time :) If you are an Agile Coach or Practitioner or Scrum Master, I recommend you to make use of Agile Games and you should consider it because [1]Games are fun [2]It helps to reach consensus faster by understanding everyone's perspective [3]Everyone's objective is common i.e. To Win.  For instance, we had played "20/20 Vision: For Understanding Customer Priorities"

 

You may register for such games at http://www.innovationgames.com/agile-teams/ and also there are many such websites which allow you to download content of games and play them live on their website, use it at your convenience. 

Playing and Learning with Agile Game

Game: 20/20 Vision [Understanding Customer Priorities]

After each topic, I had asked teams to highlight their experience about the areas, where they were expected to talk about [1]what went well so far ? [2]what didn't go well ?  This had paid off remarkably well as it helped each participant to learn from everyone else's experience, and allowed everyone to come up with solution and all I had to do is facilitate it. 

 

We continued this effort even after the event, as on today I have received about 90 emails from participants, the subject/content are pretty much common and almost everyone's tone were similar [1]they have described the challenges they are facing, [2]why they are facing such challenges they think, [3]they suggested solutions to overcome them using agile best practices and [4]all they were seeking from was reflection or confirmation if their plans were on the right track and we learnt to continue to adapt. I am extremely happy to receive such emails and I welcome more because from everyone's experience I am learning a lot. Also it allows individuals/teams to think about solutions and strategies, while keeping best practices in mind as ultimately the fun is to see everyone improving continuously and at their own.

Finally I published a survey to receive feedback about the event and I am immensely happy to see the NPS score on the highest side, people are willing to join such events again and this has triggered Red Hat Core Agile Ambassadors team to focus on APAC.

 

I thank everyone who had helped me to host the event at Red Hat Beijing office. Also I thank everyone for such grand reception, for participating and contributing to the Agile Open Day. 

 

Be Agile! 

A Practical Guide: Story Points-Based Estimation

Glad to see that my article made it +Scrum Alliance

http://www.scrumalliance.org/community/articles/2014/january/a-practical-guide-story-points-based-estimation

Get Real

An introduction to Smaller, faster, better way to build software. Well then, it's time to skip all the unnecessary stuff and focus on build the real thing. Some of it I have listed here which you can stop doing and build the real thing.

Let's get rid of >>>>

Timelines that take months or even years

Pie-in-the-sky functional specs

Scalability debates

Interminable staff meetings

Useless paperwork E.g. charts, graphs, boxes, arrows, schematics etc.

The “need” to hire dozens of employees

Meaningless version numbers

Pristine roadmaps that predict the perfect future

Endless preference options

Outsourced support

Unrealistic user testing

Top-down hierarchy

Let me know if above these helped you anyway ever to build the real thing.

***Then how to build the real thing!

Do you remember Agile Manifesto(s) ? Read more

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer Collaboration over contract negotiation

• Responding to change over following a plan

Interestingly if you follow what I have listed above and get rid of the ones I mentioned, you will see how quickly you be adapting to these new changes and start building the real thing early before your competitor builds it :-) Sounds easy ! Well then it's time to Be Agile and follow Scrum !

With the advent of Object Oriented Software development methods it became easy to break large software projects into very small components and therefore able to take advantage of the building incrementally during Sprint, build the MOST important feature first. Since each sprint outcome is working element of the product this ensures rapid feedback and adjustment to the changing needs to the marketplaces.

Let me provide you an quick introduction to Scrum Vocabulary (Note: this is probably the smallest introduction I have ever written :-) So feel free to read other relevant ones you will find in my blog)

What is it ? 

Scrum provides a language for this common sense way of organizing, performing, and managing work.

Product Backlog:

All work to be performed in the foreseeable future, both well-defined and requiring further definition.

Sprint:

A period of 30 days or less where a set of work will be performed to create a deliverable.

Sprint Backlog:

That work that is well enough defined that it can be worked on with relatively little change over a period of 30 days or less and will result in a tangible, incremental deliverable.

Scrum:

A daily meeting at which progress and impediments to progress is reviewed.

Do you agree with me with the benefits of Getting Real ?

Getting Real delivers better results because it forces you to deal with the actual problems you’re trying to solve instead of your ideas about those problems. It forces you to deal with reality.

Getting Real foregoes functional specs and other transitory documentation in favor of building real screens. A functional spec is make-believe, an illusion of agreement, while an actual web page is reality. That’s what your customers (whether internal or external) are going to see and use. That’s what matters. Getting Real gets you there faster. That means you’re making software decisions based on the real thing instead of abstract notions.

Finally, Getting Real is an approach ideally suited to web or mobile-based software. The old school model of shipping software in a box and then waiting a year or two to deliver an update is fading away. Unlike installed software, web apps can constantly evolve on a day-to-day basis. So far it I have taken advantage of this approach of Getting Real. Are you thinking ? I think it's worth a try! 

How to write User Story ?

Over the years I have worked with quite a few Product Owners and also I have played that role myself but often I have seen people having very minimal knowledge about writing good user story and that does impact development. So this post is all about it how to write good user story!

Before I get into it I prefer to put an example of how an user story should be written:

If you notice this example meets the following high level definition of what a Product Owner should write:

• Provides a simple medium for
• Gathering basic information about stories
• Recording high-level requirements
• Developing work estimates
• Defining acceptance tests [Normally been written in the back of 4"X6" card, however if you are using any online tool most of them provide acceptance criteria block.

• Acts as agreements between customers and team members to discuss detail requirements during an iteration

However, here I have put together the detail definition we should capture in user story and here the participants are Team and Product Owner who needs to write this together:

• Story identifier and name
• Story description: A sentence or two that describes the feature in customer terms
• Story type (C = customer domain, T = technology domain) [E.g. customer domain would be something which comes from customer thus this is nothing but features whereas something would be called as technology domain which comes from the team say refactor certain area of the code or support they need to get something done etc.]
• Estimated work effort: The estimated work effort needed to deliver the story, including time for requirements gathering, design, coding, testing and documentation.
• Estimated Value Points
• Requirements uncertainty (erratic, fluctuating, routine, stable): An "exploration factor" for a specific story
• Story dependencies: Dependencies that could influence implementation sequencing
• Acceptance tests: Criteria the customer team will use to accept or reject the story.