Blog

Agile Retrospectives: Do they add any business value?

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.

Understanding the Team Culture and Requirements

As a coach, it is very complex sometimes how the team who's been coached takes into consideration the minute facts of coaching dynamics and delicacy of human emotions. The turf, as I call it becomes very slippery for the coach to walk on if that’s the case. Agility comes from the fact that everyone should be on the same page about changes that are coming, and discipline that is required to execute that change and gain that acceleration which the organization is looking for.

The role of a Scrum Master in a Distributed Agile Team

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.

Selling Agile to Senior Management

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:

Role of Software Architect in Agile Projects

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]

Building Quality into Multi-Speed IT for Digital Transformation Success

Rise of the Chatbots!

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.

Puppetized!

Dockerized!