Once a scrum master shared a concern that the retrospectives
have become boring and neither she nor her team members feel any value out of
it. We all have faced this challenge in the past and would like to share few
pointers than can be considered as good guiding principles for retrospectives
and why they are the strongest tool in the agile toolbox to make any team
better, and it does deliver business value.
Sharing outcomes of previous meetings
People tend to abstain if they find that nothing from
previous retrospection has improved. The difference I have observed when
sharing the outcomes with the team is that they do realize that few items under
‘areas of improvement; in the past has become ‘things that went well’ in the
sprint. Also when discussing on thing to changes, ask team’s opinion on action
plan and come to an agreement. Caution: Do not force yourself to prove
everything has improved; be honest in admitting that some things have not
Pat on the back
When team members do something exceptional, we should try to
appreciate them in person and give them a pat on their back. The retrospectives
are a good occasion to reiterate and call out those performances. Wait for your
other team members to do it and if they miss, make sure you as scrum master
call them out. Nothing motivates a team member than a co-member’s appreciation.
Also encourage your Product Owners and Business Leaders to send formal
appreciations and it works well when you have distributed teams.
Coach them to be prepared
Coach them to be prepared for the meeting. When you a see a
‘mistake in the past’ tend to repeat, gently remind the team, before it occurs.
Any new issue you see impacting the team, remind them that we can discuss in
retro. During meeting encourage them to speak more based on data points than
being generic, focus more on things that are controllable within the team. Make
sure everyone get a chance to speak.
Change the meeting pattern
The same meeting pattern sometimes makes retrospectives
boring. Mapping your sprint to something from real life can add real fun and
would help fresh ideas. Compare your sprint to a baseball / cricket/soccer
game. Questions using game terminologies like- Did the team had enough
preparations to get in to game, which half did they play well , what should
they try different in next game would give different perspective to the thought
Press the SOS button – Escalation
While captaining your ship, if you see issues disturbing the
team recurrently, do not hesitate to escalate. Environmental issues, build
failures, domains not resolving dependencies etc. cause disruptions, especially
if you have short sprint durations. Escalate to senior management.
Show them the trends based on Metrics
Sharing sprint metrics like team average velocity, bugs
logged in the sprint; team commitment accuracy etc. during retrospection helps
the team to understand the trends on how they are performing. I have seen that
it has enabled them to make their own decisions in terms of how much stories
they can commit to, come up with ideas to reduce defects etc.
Say Thank you!!
Ending the meeting with a Thank you, appreciating their
active participation does matter a lot. It creates a feeling of being important
and listened and this instills a sense of belonging. Also when they see their
suggestions are put in to actions, they will actively involve in future
The roles and responsibilities of the Scrum Master may vary based on the distribution environment and team structure, but there is always a component that seems to be common for all cases, and this is ensuring that the team is following Agile practices. It becomes imperative in the distributed environment since most of those practices were initially designed for the collocated teams. As a Scrum Master, she/he is responsible for coaching the team and helping them overcome those challenges.
Distributed teams can adopt not all Agile practices; some have to be significantly modified, and some will require specific tools, which means that the team will have to invest in some learning time to adopt them. One of the classic examples of those modifications is pair programming. In distributed Agile environments, pair programming is replaced with code reviews. (Personally, I have found code reviews more efficient that pair programming even within the collocated teams).
Another practice that is critical in a distributed environment is continuous integration which will ensure that everybody is working on the same code. The implementation of this practice can be challenging from the technical point of view but is well worth the investment. It also requires that all team members understand the importance of daily code check in, even though the particular feature they are working on may not be finished. If the code is throwing exceptions or prohibiting any previous functionality from testing, it should be commented out, but still checked in. The Scrum master is responsible for communicating the importance of Agile practices to all team members.
One of the other Scrum master responsibilities usually includes tracking iteration progress. In collocated environments. Iteration tracking is visualized by sticky notes on a wall so that every team member can see the current status of the particular issue, and update the status on items assigned to him during the daily standup meeting. In distributed environment, you need to use something more advanced to visualize the progress. There are fairly large numbers of tools available today in the market which do an excellent job of visualizing iteration tasks, keeping track of backlog items, and generating burn down charts.
This is an excerpt from the forthcoming book, The Art of Being Agile.
The best way to promote Agile to senior management is to explain its numerous benefits and cost and waste reduction methods. Once key players in the organization are made aware of Agile’s benefits, it essentially sells itself. And, the best way to sell a methodology is to demonstrate its value by delivering quantifiable and visible business benefits, but to even get there, you first need to find a project that you can implement using Agile, and this is a challenge in itself.
The process of selling usually starts with a presentation to the key decision makers, which should at least cover the following areas:
- Changes required in this particular department (team, tools, meetings)
- Overview of Agile process (two to three slides)
- Overview of user stories and how they relate to the requirements
- Overview of tools required
- Overview of general Agile benefits with a focus on how this particular company/department/project will benefit from Agile (reduced documentation overhead, better progress tracking, improved code quality, faster delivery, more efficient analysis of scope changes, customer satisfaction, short feedback loops, etc.)
Another very important step at this stage is to determine general expectations for Agile from senior management and to make sure they understand that Agile is not a magic solution. Some non-biased measures, as well as the success criteria for implementing Agile within a specific project, have to be defined.
Let’s return to the benefits outlined previously and see how they can be measured since some of them are very tricky (for example, it’s not always easy to measure customer satisfaction or the ability to react to changes in the requirements) here are a few general recommendations:
- Reduce documentation overhead
- Code quality
- Better progress tracking
- Faster delivery
Once you’ve obtained a general approval to test Agile you need to find a project that will demonstrate all the good things you promised in your presentation. Finding the right candidate is extremely critical and not an easy job to any extent.
This is an excerpt from the forthcoming book, The Art of Being Agile.
[Image Courtesy: Flickr/Agile/quite-silence]
One of the biggest misconceptions about Agile is that architecture is not required in the Agile development. ‘We‘re Agile; we don’t need architecture’–is something that everybody involved in Agile has heard at least once.
Let’s start by establishing a common understanding of what the software architecture is, to which everyone can agree. The definition of architecture is quite broad, and the roles and responsibilities of software architects vary dramatically from company to company.
Here is how Martin Fowler identifies architecture in Patterns of Enterprise Application Architecture:
“Architecture” is a term that lots of people try to define, with little agreement. There are two common elements: one is the highest-level breakdown of a system into its parts; the other–decisions that are hard to change.”
I find that we all can agree on those two common elements. Do we need the highest-level system break down? Absolutely. Do we need huge documents and long design stages? No. Agile is not against the architecture–it’s against useless, bulky documentation that nobody reads anyway.
From the perspective of change, the role of architecture in Agile development becomes quite clear – A good architecture is responsive and will support agility; a poor architecture will resist it and reduce it. And, since one of the benefits of adopting Agile is a better response to changes in the requirements, it’s obvious that flexible and extendable architecture is a key to this.
The biggest issue that I’ve noticed is the very thin line between architectural design and software design. I’ve seen companies where the different implementations of the following practice were used: Architects created design documentation and developers were responsible for writing the code. This introduced a myriad of problems, starting with developers feeling that they were not fully trusted. This also gave developers an excuse not to really think about the design. ‘We’re just coders, not responsible for the design and we do only what we are told to do.’ is a common attitude that I have witnessed. In Agile, the developer is responsible for the code he writes (and unit tests) as well as the design since nobody else will provide him with it.
Ideally, the high-level software architecture is completed before coding starts. And I really have to be careful here – completed doesn’t mean written in stone; it can change, but with an understanding “this is the best of what we know right now.” This doesn’t necessarily include a database design or class diagram, and the level of details really depends on the approach you will be taking moving forward. I found that for certain systems the Domain Drive Design (DDD) is extremely useful and has made my life far easier. Therefore, I like to have a domain model and a basic set of domain classes and their relations defined, but not to the level of methods and attributes.
Personally, I prefer projects to have a design stage; this is when the high-level business domain model and user stories are created. At this stage the main architectural decisions are made – the technology that will be used, the database server, the application type (for example, Mobile, rich client, or service), the architecture style (client server, layered architecture, SOA) is selected, and the architectural frame that will be applied is selected as well. The document created during this phase is not solely architectural effort, it is a collaborative effort of business analysts, developers, and network administrators. The output of this design stage is not only a high-level architectural document. (This is not an attempt to make fixed predictions of the future or create a detailed software design upfront as this approach places all the significant decisions at the point of least knowledge in a project’s lifecycle). This is simply a way of getting and sharing the common understanding of the system we are all about to develop.
This is an excerpt from the forthcoming book, The Art of Being Agile.
[Image Courtesy: Flickr/Helix/Philip Gunkel]
In light of building a contemporary digital experience and social engagement, the rise of the Chatbots is quite an advent when combined with the latest tools & technologies. We have clearly seen a growth in digital concierge services from Apple (Siri), Google (GoogleNow), and Amazon (Echo) in past coupled of years if not more – the use of common language and communication with digital devices is increasingly becoming a standard. As Dion Hinchcliffe explicitly references, IRC Bots, Eliza, & Zork – the latter, command line programs from 80’s, and the former Internet Relay Chat (IRC) that used to perform automated functions to control the IRC Channels back in the day when I was in high school working on dial-ups.
Today, the world is different, and the Chatbots are a self-learning and evolving machine – they are the new frontier for brand & consumer interaction. Uber’s Messina describes it as ‘Conversational Commerce’, and Facebook’s Zuckerburg describes as the ‘next big thing’ that is being worked on now at Facebook, and they’ve built a Chatbot roadmap of sorts.
How do Chatbots work?
Chatbots work differently, and they have a human-built intellect that is fed over a course of time and developed using data which is curated based on an archival process of scenarios and cases. The knowledge experience part comes from the business logic and machine learning, and the constant communication of the connected devices (apps, devices, APIs, DBs) which are feeding into the business logic. So your Chatbot essentially becomes a self-learning machine which should get better and better over time. The information feeders to Chatbot are multi-channel user interfaces – so any data that is visible to us eventually gets fed into its knowledge portal. The accumulated data gets further curated through machine learning and is then queried on through algorithms which utilize the power of cloud computing.
So what’s in it for companies?
For Social Media companies – it’s about connecting users with their brands, and for brands, it’s about their products, brand loyalty, and customer service. And this all leads to the monies. Companies, or in this case the guinea-pig pioneers within social media and brands that are looking at Chatbots as a way to monetize into the building hype of ‘conversational commerce’, and also, as a way forward to potentially change they interact with customers today.
So how should one get started on Chatbot?
Follow a minimalistic approach – solve a simple problem and then bring complexity. The power of natural language – where users can query simple things – such as service type, any recommendation or what next product to choose from – could be a simple but good start. Worth for brands which are user conscious.
[image courtesy: tabletop assistant / MattHurst via Flickr CC Licence By]