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: ensuring that the team is following Agile practices. This 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 and helping the team overcome those challenges.

Distributed teams can adopt not all Agile practices; some have to be significantly modified, and some will require specific tools, meaning 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. (I have found code reviews more efficient than pair programming, even within the collocated teams).

Another critical practice in a distributed environment is continuous integration, ensuring that everybody is working on the same code. Implementing this practice can be challenging from a technical point of view, but it 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 still need to be finished. If the code throws exceptions or prohibits 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 a distributed environment, you need to use something more advanced to visualize the progress. Many tools available today in the market 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 role of a Scrum Master in a Distributed Agile Team was originally published in Manoj Khanna on Medium, where people are continuing the conversation by highlighting and responding to this story.

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]

Selling Agile to Senior Management was originally published in Manoj Khanna on Medium, where people are continuing the conversation by highlighting and responding to this story.

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]

Role of Software Architect in Agile Projects was originally published in Manoj Khanna on Medium, where people are continuing the conversation by highlighting and responding to this story.

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]

Rise of the Chatbots! was originally published in Manoj Khanna on Medium, where people are continuing the conversation by highlighting and responding to this story.

Puppetized! was originally published in Manoj Khanna on Medium, where people are continuing the conversation by highlighting and responding to this story.

Dockerized! was originally published in Manoj Khanna on Medium, where people are continuing the conversation by highlighting and responding to this story.

Feedback occurs when the return of information concerning the results of a process or activity takes place (http://www.thefreedictionary.com.). This event is part of a chain of cause-and-effect that forms a loop onto itself. Feedback comes in two forms: good feedback and bad feedback. Without feedback, the Agile process of inspection and adaption could not occur. An Agile process thrives in an environment with constant change. Because of this variability, adaptation and adjustment points are made on a regular basis. If we can shorten the amount of time elapsed between these calibration points, then we can more quickly adapt to these changing realities. In short, this is the feedback loop in our process and environment.

Types of Feedback

There are, however, different forms of feedback, which are listed here for the reader’s reference and throughout:

1. Communication feedback (e.g., onsite customer, open team workspace, ubiquitous language)
2. Technology feedback (tools we use to give us quick feedback, like Cruise Control, mocking, BigVisibleCruise, CCtray, Resharper, TFS real time compilation/warnings, and confirming that we use the right technology)
3. Requirement feedback (when a customer need realizes in a demo or the production environment)
4. Market feedback (to see how the market reacts to a new story/feature/module, frequent and numerous deployments)
5. Analysis, design and coding feedback (e.g., pair programming, whiteboard mockups, code reviews)
6. Defect and testing feedback (the quicker we find out about bugs, the quicker we can fix them, deploying often and always, test driven development)
7. Operational feedback (process, methodologies, practices and how to improve them)

The quicker we can get these forms of feedback from the source, the faster we can validate our progress and adapt to the information received.

A company’s ability to deal with change and adapt accordingly to changing conditions will improve its competitiveness in the marketplace. Companies that struggle with a slow feedback loop will find themselves caught up in trying to solve problems that have already changed or are not important anymore.

Effects of a fast feedback loop

Having a fast feedback loop allows dominance of a company during market changes. For example, one of our clients using our health and safety management system had a deadline for submission of reports. Approximately 800 companies assigned to each performed various tasks and submitted reports showing the work completed. There were some features and latency problems that the client wanted to be fixed, and the deadline was one week away. We were able to get quickly the high-priority features added, and latency issues resolved three days into the week using our engineering practices, automated testing, and automated deployments. We went live before the deadline to get much-needed feedback on our changes in a real production environment. If we had waited until after the deadline, we wouldn’t have obtained the actual feedback from the end users re the added features, nor the feedback from an environment production perspective, since the client wouldn’t be using the system until the next deadline, which was months away. Using this feedback from deployed features in a production environment allowed us to make more improvements so that the next period time would go even more smoothly.

Summary

Being able to perform a full cycle of development from client request to production deployment in a few days helps ensure the company can quickly adapt to changing market conditions.
(This is an excerpt from the mini book series “Agile from the Trenches: The Feedback Loop”)

Understanding the feedback in ‘The Feedback Loop’ was originally published in Manoj Khanna on Medium, where people are continuing the conversation by highlighting and responding to this story.