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! 

AGILE! Who cares - Tell me what to do - Presented at Agile Day Conference 2014

Thanks for everyone's interest about the title and the topic I covered. So I have decided to upload the slides to slideshare and here is the link here

Agile Day Conference Pune 2014

Friday,18th July last week, I had an opportunity to attend and present my paper at AgileDayConference. ADC 2014 was built on the theme of "Agile Testing - Embrace Quality, Deliver Superior Business Value.". This conference aimed to underline tools, techniques, developments and best practices in Agile Testing which will act as catalysts to deliver premium business value alongside sustaining quality. Conference was very informative and I learned about best practices, tools used by other organizations. Overall it was prodigious experience to hear fellow speakers & distinguished coaches. I would definitely like to take a moment and Thank the organizer KnowledgeHut for hosting it and Kudos for doing such a good job with the arrangements. Also I would like to thank the Advisory Board for choosing my paper and sponsors Scrum Alliance, JamBuster and PMI.  

It was thumping to hear agile adoption stories from fellow Agile Practitioners, Evangelist, Process Champions, consisting a very diverse set of audience ranging from companies like Amdocs, Thoughtworks, Mahindra Comviva, Invesco, JamBuster, Hexaware, CeeZone, Faichi Solutions, Atos, Wipro, Tech Mahindra, RiseSmart, Cuelogic, Capgemini , Cognizant, Webonise Lab, Cross Country Infotech, ComputerLand UK, SJ Innovation, Accelya Kale Solutions and many others (sorry can't quite remember all other names). 

In the event , I presented this paper "AGILE! Who cares - Tell Me What To Do", this was about Agile Transformation Strategy, where I highlighted challenges, listed out strategies which worked well for me to overcome such challenges and explained how to use change management best practices effectively in enterprise context. 

Although my talk was the last talk of the day and was just for 35 mins but in the end it was great to find the interest level of the audience and questions. I was delighted to see everyone being pleasantly surprised to hear about Dr. John Kotter's, "8-Step Process for Leading Change" and how same can be used by Coaches, Agile Practitioner and Change Agents for driving "Change" at organizational level.

In the end, I closed the talk with following:
Remember - You can’t win it all and That’s OK.

But don't let it go so easily

Make It Stick - Create a new culture

Hold on the new ways of behaving and make sure they succeed, until 

they become strong enough to replace old tradition

Build Trust

Value Results

Build agile teams that truly engage self-direction
Be Agile!

Thanks everyone @ADC for responding so passionately about the subject and for your appreciation.

Last but not the least, Thanks to Sankarshan for sharing the link of ADC 2014. 

Otherwise I may not even submitted the proposal for the talk.

Today I am Speaking at Agile Day Conference in Pune

I thank KnowledgeHut & the selection committee for giving me the opportunity to present my paper "AGILE! Who cares - Tell Me What To Do". This is about Agile Transformation Strategy, where I will be highlighting areas which often go wrong, will discuss change management in general and list out strategies to overcome them.

Hoping to see a very enthusiastic audience and looking at this as great networking opportunity. 

Note: Those who are attending the conference is taking home 7 PDUs from PMI, 8 SEUs from Scrum Alliance and this means conference is heavily backed by PMI & Scrum Alliance.

Sprint Review

WARNING: On the surface, this Scrum activity appears to be both simple and straightforward. But be warned: without careful preparation, this session can lead to riotous table-thumping and streams of tears.

Just show the stakeholders what was completed over the sprint (past 2 weeks) — sounds simple right? Well, based on my experience, a sprint review is rarely simple, and in fact, I consider it to be the most delicate session to facilitate.

The core issue is aligning the expectations of a disparate group of stakeholders. These people are often more senior in the business relative to the team, they most certainly have less familiarity with the project compared to the team.

Scene Setting

Before you show any output during demo please explain why we are doing this. I am not saying you have to start from the beginning from envisioning phase of the product but definitely try explaining where you were left last sprint and what you are planning to achieve this sprint. Also it doesn’t hurt to explain the definition of done. This should help to set the stage.

Here is great video which explains why often "why" (http://goo.gl/yjmdNO) is so important

The Main Event - Sprint Review

To ensure the main event goes smoothly here are few recommended steps which you may consider to take to provide better experience for everyone.

Remember preparation is the key for the sprint review meeting and that should happen prior to the sprint review meeting. Identify user stories you are planning to demonstrate before the sprint review.

   1. Prepare a demo workflow script
   2. Prepare some basic demo data.
   3. Ensure the demo environment is working as expected. We don't want to be stuck during demo.

You don’t want the team to spend too much time on these tasks, as the sprint review shouldn’t be turned into a dog-and-pony show, but these tasks certainly need to be acknowledged. There are also a few important points to stress to the team during sprint planning.

Instead of a one-way showcase, the demo of the sprint’s completed work should act as a prompt to encourage a two-way conversation between the business and the Scrum team. It should be an open and honest discussion focusing on what was completed and what is coming up next.

Remember that this session should not become a smoke-and-mirrors slide show presentation to impress the attending stakeholders. I assure you that misleading demonstrations will only come back to bite everyone.

Preview at the Review

It is a fundamental tenet that during the sprint review, the team should demonstrate only stories that meet the definition of done. It makes sense, but it can be very frustrating for some stakeholders, and the reality is that the team will possibly receive pressure to still show what has been worked on (even if it is not quite finished).

In this situation, instead of being a stubborn mule, I recommend creating an additional agenda item labeled “Coming Soon.” This way, much like a movie preview, there is acknowledgment that the work isn’t complete, yet the stakeholders still get a sense of work that’s on the boiler and is coming soon to a sprint review near you!

Impediments

Following the show, it can also be a good idea to discuss any impediments that impacted the sprint, including why they occurred and how they were dealt with. This is an opportunity to lobby for greater assistance if there are any systemic impediments. An example might be the physical environment—perhaps a problem dealing with the facilities department in your mission to get larger desks or more breakout space.

In addition, I recommend using this segment to briefly make a point of key process improvements that were implemented to help achieve the sprint goal. Don’t go into detail here, as this session is about reviewing the product, but a quick mention won’t hurt and is a great opportunity to demonstrate to the stakeholders that the team is constantly improving.

So-Called Suggestions

There will no doubt be a range of questions and suggestions that surface throughout the session. I recommend that questions be controlled and kept on topic. The team should answer any and all questions that surface in relation to what is being demonstrated; however, questions that are tangential or completely off topic should be taken “offline” in a separate meeting.

Acknowledge any suggestions made (no matter how outlandish they might sound) by writing them down somewhere. Any valuable suggestions which is related to the product should of course be added for further discussions under "Discussions" list and in future you may consider to discuss the item with Product Owner and after approval move it to "Product Backlog".

Picnics or Battles

Sprint reviews can be akin to turning up for a picnic or, alternatively, turning up for pitched battle! It comes down to taking the necessary precautions and treating each session seriously while still having some fun. Don’t assume that everyone has the same level of background as the team, and ensure that all attendees are made to feel comfortable by always explaining what is happening and why.

Aligning everyone’s expectations is the name of the game, and achieving this objective is critical if you prefer picnics to battles!

An introduction to Behavior-Driven Development

View it at slideshare http://www.slideshare.net/SumanGuha/an-introduction-to-bdd

Exam tips for PMI ACP Certification from PMI Agile Certified Practitioner

Recently I have passed PMI-ACP exam :-) with highest band and yes I am now an PMI-ACP Certified Practitioner. This post is about my experience, preparation strategy and also I am trying to cover exam's prerequisites and requirements.  

I have noticed I found many follow forums or professional networking sites LinkedIn to find out if they want to be certified or not and it is always a hotly debated topic. With valid arguments on both sides, my personal decision was Yes, I wanted to get certified. Looking back, I have to say that I didn’t regret it. Not only it opened but some interesting ones too. In-fact I learned a lot (and started to actively use my knowledge) just by studying for the test and going through cases. 

According to PMI, The PMI-ACP recognizes knowledge of agile principles, practices and tools and techniques across agile methodologies. In order to be certified, you need to demonstrate the following and pass 3 hours exam by answering 120 questions.

My preparation strategy

First of all, the below reflects my personal experience only. Everybody’s story is different. You may already be an agile guru by experience or may be fairly new and need extra effort to prepare.

My first advise would be to join one of the PMI-ACP study groups on LinkedIn. In my case, I have been an Agile Coach for past 6 years but still the information I got from these groups was instrumental in my preparation. 

In order to satisfy the 21 educational PDU requirements, I opted for classroom training at simplilearn and also had access to there online course materials and exams. I wouldn't recommend just sticking to these notes of any tutorials rather read the main preparation book and it was Mike Griffin’s Exam Prep Book. I loved it! Really great summary at the right level of details. Overall for the exam I spent 4 weekends (i.e. 4x2=8 days) of studying because apart from weekends I was busy with my work with Red Hat. But this may vary from person to person and probably in my case since I have implemented agile practices across teams it was not extremely difficult to pass the exam. However, keep one thing in mind you need to cover the entire book and I recommend you to not skip any material. 

Take Mock tests for real exam

For final exam I have taken mock tests from quite a few sites. But mainly I have subscribed to agileexams.com for $49 which comes with 30 days membership and taken multiple short exams(25 questions in each exam) and two full exams (120 questions in exam). Fun with agileexams.com  you can take as many as exams you like and remember to review answers understanding why something is incorrect or even for that matter correct is very important because in real PMI-ACP exam you will be tested based on your understanding. Apart from that you may also take exams from following:

1. Free Full test 120 Q @ http://www.simplilearn.com/free-resources/pmi-acp-agile
2. Sample 20 Questions @ http://www.ucertify.com/exams/PMI/PMI-ACP.html
3. Free 30 Questions / exam simulator @ http://www.gr8pm.com
4. http://agiletraining.com/2011/09/24/pmi-acp-agile-certification-exam-study-tips/
5. http://pmiacptraining.com/
6. http://whitewaterprojects.com/pmi-acp-sample-exam/#
7. http://www.agiledream.com
8. http://www.proprofs.com/quiz-school/story.php?title=pmiacp
9. http://www.rmcproject.com/pmi-acp/pmi-acp-FreeContent.aspx

Exam experience

I took the exam at the Prometric center which was about 9kms from my home.

Overall my experience wasn’t very much different from what I have learned by reading other task takers comments. I had a balanced set of questions with most of them related to Scrum,XP, Lean,few risk management & Kanban questions, a good portion of situation questions, some questions on the manifesto / agile values, and some tricky ones on agile portfolio management, EVM, and costs.

I wouldn't call the test very difficult but it was challenging enough to keep me thinking very very carefully about my answers. It was more focused on testing the understanding and practical applications of the core agile values rather then on simply testing how well you remember the definitions. In other words, I encountered more “why”, “how”, and “when” then simple “what is ..” questions. Usually out of 4 answers 2 were obviously wrong but I had to choose carefully between the remaining 2. I managed to finish all 120 questions in 2 hours (120 minutes) and spent another hour reviewing my answers. The results are known immediately once you finish the test and you get a temporary certificate on the spot. Also you will be able to down the certificate from the PMI website. Few weeks later you’ll get the proper certificate by mail and waiting to receive it.

An overview of Test Driven Development (TDD)

It is also known as test-driven development (TDD) or test-first programming (TFD).

Test-first development, or test-driven development, is a rapid cycle of testing, coding, and refactoring. When adding a feature, a pair may perform dozens of these cycles, implementing and refining the software in baby steps until there is nothing left to add and nothing left to take away. Kent Beck, who is credited with having developed or 'rediscovered' the technique, stated in 2003 that TDD encourages simple designs and inspires confidence.

It is an evolutionary (iterative and incremental) approach to programming where Agile software developers must first write a test before they write new functional code. It is one of the Extreme Programming(XP) practices.

Steps:

1. Quickly add a test, basically just enough code so that the tests now fail.
2. Run the tests, often the complete test suite, although for sake of speed they may run only a subset to ensure that the new test does in fact fail.
3. Update the functional code so it passes the new test.
4. Run the tests again.
5. If the tests fail return to step 3.
6. Once the tests pass the next step is to start over (agilists may also want to refactor any duplication out of their design as needed).

Advantages of TDD:

• TDD forces developers to do detailed design just in time (JIT) before writing the code.
• It ensures that agile developers have testing code available to validate their work, ensuring that they test as often and early as possible.
• It gives developers the courage to refactor their code to keep it in the highest quality possible, because they know there is a test suite in place that will detect if they have “broken” anything as the result of refactoring.
• Research shows that TDD substantially reduces the incidence of defects.
• It also helps improve your design, documents your public interfaces, and guards against future mistakes.

I will write more into TDD practices in upcoming posts.

The road to Continuous Delivery

Continuous Delivery it's a software development practice where you make sure that your application is ready to be deployed to production at any time. You’re not only making sure that when a developer commits a change is, it is correctly integrated by building and unit testing your application (Continuous Integration). You’re also making sure that your application is always ready to be deployed by running automated and/or acceptance tests on it and testing the release process itself.

Practicing Continuous Delivery gives you several advantages:

+The time from idea to deployment to production (cycle time), is shortened.

+By shipping the product early you are encouraging early feedback. The faster you get your software to your end-user, the faster you get feedback.

+You’re always ready to deploy to production. You do not have to spend time making and testing a release.

+Because you’ve already tested the release process itself, deploying to production is simple and error-free.

+You are getting ahead of the competition and making your release process a business advantage.

How to implement ?

• Ensure both your developers and system administrators are responsible for deployment. Traditionally, the system administrator is responsible for deploying to production. By making your developers responsible too for deployment you are encouraging a culture of collaboration (DevOps) and lowers the chance of errors due to miscommunication.
• Find out what your release process looks like, make it reliable and repeatable and automate as much as possible. Make every step of the process reliable and repeatable. When your steps are reliable and repeatable, then they can also be automated. As our goal is to automate each step.
• Setup one single way of deployment to an environment. Make sure that you define a single way to deploy a release to an environment, whether is it the test environment or to production. If you do this, then you’re also testing your deployment process itself.
• Test on a production-like environment. If you test on a different environment than your production environment, then there is a risk that your deployment to production doesn’t work or worse: your end-users experience runtime problems due to different software versions of third-party software and libraries.
• Quality first Keeping your application deployable should get higher priority than adding new features. If an error in your release process occurs, fix it as soon as possible.

Where do I start ?

It takes effort to fully practice Continuous Delivery. But you may start slowly by:

• Let your developers and system administrators work together on deploying your application.
• Visualize your release process.
• Make steps of your release process reliable and repeatable

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.

Certified Scrum Master (CSM) Training

COURSE CONTENT

The course consists of a combination of lecture, discussion, case studies, hands-on exercises, and a simulated project. The course content is 85% standard materials and 15% which is tailored to the interests of the attendees. A typical course agenda is the following: 

DAY 1 – Morning

• The Core Principles of Scrum
• Data from Teams Using Scrum -- Impact on Productivity, Morale, Quality, etc.
• Difficulties Teams Encounter, and Key Strategies for Success
• The Basic Mechanics of Scrum -- Start to Finish
• The Role of the Scrum Product Owner
• The Role of the Scrum Team
• The Role of the ScrumMaster
• The Role of Managers and others in Scrum
• The Shift from Micromanagement to Macromanagement
• Exercise: Self-Management and the Team's Commitment and Focus

DAY 1 – Afternoon

• Creating and Managing the Product Backlog
• The Sprint Planning Meeting
• Estimating Available Hours
• Backlog Item Analysis and Decomposition
• Planning the Sprint
• Potentially Shippable Product and the Team's Definition of "Done"
• Sequential versus Overlapping Development
• Sprint Planning Meeting Simulation
• The Daily Scrum
• Exercise: Dysfunctional Daily Scrum
• Scrum Artifacts
• Sprint Backlog
• Burndown Chart
• Task Boards

DAY 2 – Morning

• Intensive Hands-On Scrum Simulation, including:
• Sprint Planning Meeting
• Setup of Artifacts (Sprint Backlog, Burndown Chart, Task Board)
• Daily Scrum Cycle x 4
• Sprint Review
• Sprint Retrospective

 DAY 2 – Afternoon

• Release Planning Using Scrum
• Project Estimation and Meeting Release Date Commitments in Scrum, including Date-Driven Releases, Functionality-Driven Releases, and Date- and Functionality-Driven Releases
• Hands-on Estimating Exercise
• Using Scrum for Multi-location (Distributed) Development
• Scaling Scrum to Large Projects, including Scrum of Scrums
• Using Scrum for Fixed-Price / Fixed-Date Projects
• Handing over Scrum Exam guide and course material for CSM exam.

HIGHLIGHT

In the 2-day Certified Scrum Master training course provides a comprehensive and in-depth training in Scrum theory and practice, will be taught by a Scrum Alliance Certified Scrum Master Suman Guha (http://www.scrumalliance.org/profiles/138725-suman-guha) who has with 100% score in Scrum Master Certification and taken up corporate trainings with large enterprises.

The course format is divided equally between lecture, discussion, and exercises, with frequent opportunities to ask questions.

In addition to Scrum theory and practices, the course also includes coverage of the following topics: release planning and estimation using Scrum; managing Scrum projects to on-schedule completion; multi-location (distributed) development using Scrum.