What is Scrum? Introduction to Scrum, its Roles, and Ceremonies

What is Scrum? Introduction to Scrum, its Roles, and Ceremonies

Introduction to Scrum, its Roles, and Ceremonies

‘Scrum’ The Name Background

Scrum takes its name from a play in rugby where the players bind together in teams and try to take back possession of the ball. Injuries are common.

‘Scrum’ as in Software Development

The description above is an apt metaphor for Scrum development. It is a lightweight team-based Agile framework that is focused on getting the ball down the field in the fastest, most efficient way possible. Scrum is used for developing complex products and services with a focus on developing incremental units of business value within short iterations. It requires honesty, communication & adaptability. Just like the Rugby scrum it can be painful, but incredibly effective.

Now, let’s breakdown the components of Scrum. It is comprised of roles, ceremonies, and artifacts.

Roles

Product Owner

The Product Owner (PO) is the individual who makes the decisions on anything related to the “product”. The PO’s key responsibility is to make sure the team is developing products and features that deliver business value. The PO represents the voice of the customer and other business stakeholders. They drive the vision of the product and its features; create and prioritize the product backlog; define acceptance criteria and ultimately accepts the output from the development team. The PO is essentially an implant from the business world into the scrum team, as they are considered the product champion with the complete product know-how.

Scrum Master

The Scrum Master (SM) is the servant leader for the development team. The SM makes sure that the team is on track to deliver the product in increments and within the time-boxed sprint schedule (more on sprints in a bit). They facilitate through devotion to the scrum process, and by swiftly eliminating scrum team’s impediments. They uphold the structure of scrum, and inculcates the principles of agile within the scrum team. The SM is a facilitator for the scrum team, and makes sure that the development team is aware of what needs to be accomplished and when, and that they have the ability to self-organize to accomplish the development tasks.

Team Members / Development Team

The Team Members / Development Team (DT) are those responsible for the implementation of the product or features. These are the set of people who are actually doing the what that has been proposed and conceived through the product backlog and grooming sessions. The DT is usually a cross-disciplinary group of individuals including engineers, UI developers, Analysts and Quality Assurance. The DT self organizes and decides the best way to accomplish tasks they pick up during planning. They provide estimates on stories within the product backlog as well as provide feedback on the acceptance criteria to the PO to help keep development on the right track.

Artifacts

Product Backlog

The Product Backlog is a prioritized list of epics and stories created and managed by the Product Owner (PO). An epic is a large story and there may be smaller stories contained within. The story describes the feature in a way that makes the business value and use for the customer clear to all stakeholders so everyone can understand what is being delivered. A story is an increment of work that can be delivered by the team within the sprint cycle. Priority is set by the Product Owner, and the PO dictates the order in which stories are delivered by the team.

Sprint Backlog

The Sprint Backlog are those stories that have been committed to by the team for the upcoming or current sprint. In order to qualify to be a sprint backlog candidate stories must have enough detail (meeting the Definition of Ready – DoR) that the team is comfortable estimating the size of the story (story points) and stakeholder input/approvals have been included. The number of stories in the Sprint Backlog are determined by teams capacity built over sprint over sprint, what is also known as their velocity.

Burn Down Chart

The Burn Down Chart is the means by which the Scrum Master, team and other stakeholders keep track of progress throughout the sprint. The ideal chart would have the team incrementally completing stories throughout the sprint and thus “burning down” the Sprint Backlog to land at 0 story points left at the end of the sprint.

Sample Burn Down Chart (source: wikipedia)

Sample Burn Down Chart above – Blue line represents ideal progress, red line represents actual progress
 

Ceremonies

Product Backlog Refinement (PBR)

Backlog Grooming is the process by which the Product Owner gets their stories Sprint Ready. It involves setting the vision, proving the business case, meeting with customers and other stakeholders, conferring with the team, working with UX & visual designers. Care should be taken to get enough detail into stories that the team is clear on what needs to be delivered and why, but not so much detail that analysis paralysis occurs. Grooming sessions with the team should be time-boxed to make sure their time is spent optimally and mostly devoted to getting actual work done delivering items for the current sprint. A typical grooming session lasts for about 2-4 hrs depending on the length of the sprint, and the development team has to make sure that each story meets their DoR as an input to the Sprint, and the acceptance criteria and assumptions meet Definition of Done (DoD) for the final approval of the story.

Sprint Planning

The Sprint is time-boxed cycle that is 1 – 4 weeks in duration. At the end of the Sprint an increment of the product should be completed and ideally delivered to the customer. Sprint Planning is the session run by the Scrum Master where the team decides how many stories they can take into the upcoming sprint. The team selects stories in priority order set by the Product Owner. A team that has been working together for several sprints or more will have a historic record of how many story points they can take into a sprint. This is referred to as their velocity. Ideally their velocity will increase over time as the team builds. The objective of the sprint planning is to commit stories for the upcoming sprint to the PO, and identify all activities required for the development of the story to meet the DoD.

Daily Standup (Scrum)

The Daily Standup or Scrum is facilitated by the Scrum Master on a daily basis at the same time everyday without fail for the development team. It is time-boxed to only 15 minutes. Each member of the development team comes on time, and answers three questions – what did they work on yesterday, what are they focused on working today and if there are any impediments in their way. Impediments are noted by the Scrum Master and taken to be discussed offline, and are addressed following the standup.

Retrospective

The Retrospective is a crucial ceremony in Scrum that invites Development Team Members to give an honest assessment of their team’s performance in recent sprint. It is facilitated by the Scrum Master, and may or may not include the Product Owner. Some teams may need the Retrospective as a place to discuss issues with the Product Owner and in that case may need them to be excluded to allow for open communication. Team Members each provide a list of the following categories: “Start Doing”; “Stop Doing”; & “Continue Doing”. These may be framed in different ways but basically the conversation should be open and constructive in identifying room for improvement; issues; as well as celebrating successes.

Summary

These are the basic components of Scrum. The best way to learn is to practice and each team will grow and modify the techniques to meet their unique group dynamics & development environment. Other good sources are –

Scrum Master, an Agile Role That Is Not a Project Manager

Scrum Master, an Agile Role That Is Not a Project Manager

Agile and non-agile product management require two core components – team members, who are knowledgeable about the technical components of a given project, and a leader to guide the team members through the project.  The leadership role in agile product management differs from that in non-agile product management, though, for there is the introduction of a Scrum Master, who is neither a development team member, nor a direct leader.

Non-Scrum Leadership Role

Project Manager Role Defined

In product management, the leading role is that of Project Manager, the person who is responsible for seeing the project through to success.  Essentially, this person establishes the project goals, plans the necessary steps for achieving those goals, monitors progress, and makes decisions regarding various aspects of the project.  The Project Manager is the key decision maker and commander.  In controlling the outcome of the entire project, the Project Manager must also maintain responsibility for the team’s work, making sure that they are on-track to successfully completing the project.  He sets the framework, essentially, for the team in any given project, by establishing their goals and timetable.

Scrum Leadership Roles

Product Owner

In agile product management, particularly Scrum, however, the role of Project Manager is non-existent.  The responsibilities of that role are instead divided into two leading positions – the roles of Product Owner and Scrum Master.  Of the two roles in agile product management, the Product Owner role is the closer one to that of Project Manager in non-agile methods.

Scrum Master

The Scrum Master, on the other hand, serves as an intermediary between the development team members — those working on completing sprint goals and deliverables – and the Product Owner.  The Scrum Master role differs from a Project Manager role in that the Scrum Master is more hands-on with the development team.  When a technical malfunction occurs and hinders a team member from completing their task, it falls upon the Scrum Master – not the Product Owner – to handle the issue and ensure that the team member is able to complete their work.  In non-scrum project management situations, the Project Manager would not be the one to handle such details.  The Scrum Master is responsible for eliminating any impediments that hinder the development team’s accomplishment of sprint goals, ranging from a development team member’s computer malfunction to handling an uncomfortable temperature in the work environment.  As such, part of the Scrum Master role is to work on behalf of the development team, including facilitating the team’s meetings and coaching the team towards successful self-management and completion of sprint goals; the Scrum Master is there for the team’s benefit.

The other part of the Scrum Master role is to work on behalf of the PO.  In this sense, the Scrum Master can be regarded as the “servant leader,” for he does not make large, product goal decisions as the PO would, but the Scrum Master may make decisions on how to improve the development team’s work environment in order to enhance their productivity.  The Scrum Master ensures that the team meets the PO’s project goals, namely by removing impediments to the team’s success and communicating information about the team’s progress to the PO.  He helps the PO to lead the team by holding them accountable for the project commitments that they make in each sprint, and by doing what is necessary to enhance the team’s productivity.

Essentially, the Scrum Master facilitates the work of both the development team and the Product Owner.  Though the Scrum Master does not make main project decisions as a Project Manager does, the Scrum Master is nonetheless a vital role in scrum product management.  The Scrum Master interprets and solves team issues, and works to help them maximize their productivity, which benefits the Product Owner, as well, by bringing the project closer to successful completion.

Mobile Products: Native vs. Browser

Mobile Products: Native vs. Browser

The increase in usage of digital products on mobile makes it such that many Product Owners are tackling the creation of mobile apps — and the decision between developing a native or browser app.  When creating an app, the differences between native and browser apps become undeniably pertinent.  Of the differences between the two types of apps, one of the most visible categories is capability.  In light of the differences in capabilities, native apps and browser apps each have their own benefits; the decision on how to create and deploy the app is a critical one that depends on Product Owners’ customers’ needs and whether the app is to be user-centric or app-centric.

Native Apps

Native apps are those that are developed specifically for a type of mobile device, be it the iPhone or Android. These apps must be downloaded onto the mobile device in order for users to access the apps’ content.  Native apps have elevated user experience design, relative to browser apps.  As the apps are built for specific mobile devices, native apps are created using languages, development tools, and user interface elements specific to each mobile device, which provide native apps the opportunity to be faster and more efficient for users, and to provide better user experiences in general.  By virtue of being downloaded onto the mobile device, native apps allow better control of the mobile device’s camera, and a higher ability to access the users’ contacts, as stored in the mobile device.  The apps are entirely capable with the device’s features and hardware, which is responsible for the easy access that native apps have to their respective devices’ cameras and contact lists.  Another capability unique to native apps is a potential one for the future — the use of thumbprint reading.  The requirement that native apps must be downloaded onto each user’s device provides vast potential for thumbprint reading to be incorporated into the app.  The capabilities associated with native apps are particularly beneficial for users who want convenience and more control over the activities they complete within apps.

Browser Apps

On the other hand, browser apps, also known as web apps, are internet-enabled.  They are similar to native apps in appearance and operation — they do not have browser buttons, for one — but they require an internet connection.  This key feature of browser apps enables users to access the apps’ content on their mobile devices, by way of the mobile device’s web browser, without having to download the apps onto their devices.  Browser apps are not developed to be compatible with any single mobile device; instead, they are compatible with all types of mobile devices.  Given that these apps are internet-enabled, they are more searchable and accessible, allowing them to have higher discoverability by users.  Relating to the discoverability aspect of browser apps, they are also more advanced than native apps in terms of allowing users to search, share, and bookmark content across multiple browser apps.  For users, this ability to share and bookmark across apps is not available with native apps.

Is One Better Than the Other?

Product Owners may be under the impression that browser apps are a dying type, especially given a recent article on Forbes, but  whether your app is a browser or native app will depend on your specific product goals. Those seeking to develop an app that will have lower overhead costs, less restrictions on content due to lack of an intermediary store, and wide discoverability for the app will likely want to lean towards developing a browser app.  More customer-centric products, with enhanced user experience and design will be more likely to reap those results if they are native apps.  There is also the possibility of building a hybrid app that is between a browser and native app, for those seeking to have the benefits of both types of apps.

Product Owner Basics: Prioritization

Product Owner Basics: Prioritization

For scrum product owners, there are multiple important considerations to have in mind, and high amongst them is product backlog prioritization.  Product prioritization is vital to achieving a scrum product’s objectives, and there are a number of scrum backlog prioritization techniques that product owners can embrace.  However, it is not a process that product owners can dive into; the process’ basics — including the reasons for it, how to approach it, and the results that can be expected — should be thoroughly understood in order to achieve the full potential of prioritization.

Reasons for Prioritization

One of the top, if not the top, reasons for product prioritization is to maintain clear focus on the items to be delivered.  Of the product backlog items in any given sprint, some are not immediate and may not add significant value to the final product, nor are they necessary for the other tasks that will lead to the product end-goal; prioritization is ideal for targeting and weeding out such backlog items.  Prioritization would push these items to another sprint or eliminate them altogether, leaving the most pressing and valuable backlog items to be attended to in the sprint. Another core reason for conducting prioritization which relates to maintaining focus on the ultimate product, is that the process assists in keeping on-track, in terms of the schedule.  By having a clear list of tasks to tackle — as achieved by the completion of a product prioritization session — the team will know exactly what to attend to, minimizing the risk of some members focusing on non-immediate tasks, thereby resulting in not having sufficient time to complete the vital tasks at the end of the sprint.

Another reason for conducting product prioritization is that it helps to reduce the risk of not meeting the requirements necessitated by the product’s business stakeholders.  Without product prioritization, tasks that address product risks and difficult product components may not be analyzed, leading to less time for the team to address those risks.

How To Approach It

The significance of product prioritization makes it such that Product Owners seeking to optimize the results of their project cannot forego the process.  It should be noted that prioritization is not a one-time occurrence.  Each sprint should have its own product prioritization session.  New requirements and backlog tasks, which inevitably emerge with each new sprint, require a re-ranking of priorities.  Each prioritization session should be approached in the same manner.

In prioritizing product backlog items, customer satisfaction, business value, complexity, safety, and effort for implementation are aspects of each item that should be considered.  In general, when approaching the list of backlog tasks, the Product Owner and teams should consider which tasks will result in features that will generate the highest business stakeholder and customer satisfaction.  Backlog items that will allow customers to realize a high return on investment  should be at the top of the sprint’s list of tasks to complete.  In ranking the items, it is also important to consider each backlog item’s business value.  Does the item provide a long-term business benefit, or does it provide an immediate edge over the product’s competitors?  In either case, how the item ranks according to its business value depends on whether the product’s business stakeholders are aiming for long-term or more immediate results.  Product prioritization cannot be effective unless the Product Owner and teams also rank items according to how complex they will be to implement, how much effort must be invested in completing the item, and whether or not the backlog item relates to a product feature critical for the product’s function.

Once the backlog items have been analyzed from multiple angles, as discussed above, they can be ranked.  Teams can then self-organize in order to complete the tasks for that sprint.  Note that the prioritized list is not to be set in stone — it alters as new, relevant customer information is gleaned or business stakeholders’ requirements change.

The Results

It can be expected that product prioritization will lead to teams completing more of the pressing tasks and remaining on-track towards the product’s final goals.  Teams’ efforts and time will be spent valuably in each sprint, attending to the most urgent tasks — those that will ensure the most success for the product.

Understanding the Team Culture and Requirements

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.

There’s however a reality check that the coach could only take you to a certain point, hand hold you to a point with whatever your needs are for the objectives defined, but for the lifelong learning of the team things need to be placed in an order and in such a way where from the beginning the team is setup for success and not to fail.

And you might ask what is that thing which enables self-propelled interest of everyone as part of the agile team? In a bit. But first let’s look at this. The organizations who want to get to terms with the basic getting and going with agile, they come with a pre-notion to learn something, and learn something valuable, and their teams have mixed feelings. Some are experienced and expecting to new learning, some have been there for a long time and now being pushed into learning something new, some are new and excited to learn and some have higher expectations from the outcome after what they learn and earn in return. It is however not the place and the position of the coach to make those assessments, but those scenarios create a lot of varied team dynamics and sometimes result in a state where agile efforts become ineffective or seem to be halted. Any political maze could be a nightmare for the coach, and being transparent, open and honest sometimes is a big burden which the coach must carry on his or her shoulder. Though you cannot simply be quite about it, but there are few ways you can tackle them.

How to make sure that we have the right skill-set within the identified team?

You cannot. That’s the short answer. Coaching agile teams doesn’t mean eliminating people whom we think are not going to be valuable or show some sort of reluctance in learning something new. Unlike other trades, where the skills are hard learned and hard earned without at the expense of the outcome; things work differently under the agile coaching world and not at the expense of the outcome as well. You learn from failures and mistakes, and continue to improvise till you get it. If they didn’t get the first time around, you need to tell the individual that they should never give up, and yes, the fruits of labor will work out within the release cycle or by the time things look to come together from an integration perspective. And that’s the flexibility and ability we have in the structure for such a learning system.

Agile Retrospectives: Do they add any business value?

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.

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 changed.

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 process.

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 retrospections.

The role of a Scrum Master in a Distributed Agile Team

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

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:

  • 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]

Role of Software Architect in Agile Projects

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]

Rise of the Chatbots!

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.
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]

Pin It on Pinterest