By Janrain Team | Posted on December 07, 2016
As we continually strengthen the connection between our clients’ needs and our development initiatives, we’ve gone to great lengths to follow an Agile approach toward development. By employing the Scrum methodology, we’re gearing our efforts toward early and continuous delivery of technical excellence and good design to provide our clients with a single view of their customer profiles. If you are a developer or agency managing customer identities, you may be considering employing Scrum at your organization. Read on to learn about our perspective.
The words we choose to express ourselves and propose ideas matter greatly, not just in how ideas are perceived but in how the listener reacts emotionally and, ultimately, accepts or rejects the proposed ideas. Introducing a new process to a set of stakeholders is a good example: the words we choose to describe and define the new method can affect whether it is met with comfort, excitement and understanding or with fear, suspicion and trepidation. If a new process is presented too abstractly or the change is perceived as too grand, people may become fearful and reluctant, finding the adoption difficult. It is important that we mitigate this fear by proposing process changes in the clearest, least abrasive and most comfortable manner possible, with careful consideration for the right language.
If you feel that the introduction of Scrum may be met with hesitation or trepidation by management, the development team, customers, or others, try using common language to introduce the ideas, instead of the formal Scrum language found in texts such as The Scrum Guide. The formal language, though valuable in its own right, can be abstract and confusing to someone who is not already familiar with Scrum. Downplay the formality and use everyday language to carry across the commonsense Scrum concepts, presenting them in an easy-to-understand manner.
Here is one example of a common-language description of Scrum, which does not use any formal Scrum language:
The process starts by organizing all our work into one list and prioritizing each piece based on its value to the business. For each work item — feature requests, technical debt, bug fixes, etc. — we’ll create a separate ticket or notecard, with the acceptance criteria clearly written, giving us a tangible representation of the work we can use to prioritize items against each other. Make sure to evaluate each item and break it down into the smallest independent deliverable so that we can have a clear view of the overall work ahead of us. Someone will need to assume accountability for the overall prioritization of the work as well as advise on the specifications.
We’ll organize a team of developers (or whomever the team may consist of) who, as a unit, have the skills to complete the prioritized work themselves, from start to finish. It’s best if we’re able to keep the team members constant so that over time they become an increasingly efficient team together.
Once the work is broken down and prioritized, and the team is assembled, we’ll gather together as a group to determine what work we can accomplish over the course of the next two weeks. At this time, the development team can, in addition to discussing the technical details of the work, give each item a rating of complexity from 1 to 5 so that we have a general idea of how much effort each work item requires compared to the others.
When development work is underway, we’ll quickly touch base at the beginning of each day so that everyone on the team will know what everyone else is working on. It’s also a chance to call out anything blocking progress so that we can resolve those issues promptly.
At the end of the two weeks, the development team will show their work to the larger base of interested stakeholders, who will see what was accomplished and have an opportunity to give feedback or ask for change requests. After we review the work, I’ll get together with the development team to chat about how the last two weeks went and ask whether there is anything we want to do differently process-wise, going forward, to make things better.
In addition, at the end of the two weeks, we’ll quantify the amount of work we completed by summing up the 1-to-5 ratings of all the completed items. This will give us a very general estimate of how much work we can expect to complete during the next two weeks.
We will need to keep the prioritization of work up to date since changes in dependencies and the value to the company of various work items is always in flux. We can schedule, as needed, a regular meeting to make sure that our work priorities are current, acceptance criteria are clear, etc.. If we like, we can invite the development team for early technical feedback.
I’ll keep an eye on things and help facilitate the various meetings. I’ll also make sure to keep the work organized and in front of everyone. As well, I can help the team resolve any blockers they have, and help guide them to be the most effective team possible.
If you think introducing Scrum to your company or stakeholders could be met with trepidation and reluctance, don’t be overly abstract, and don’t overplay the complexity of this otherwise simple-to-understand, highly beneficial framework. It may hinder your cause to introduce this commonsense method with uncommon language. On the other hand, making some of the changes suggested above is one means to provide a more accessible introduction and pave the way for a positive perception of the changes you propose. Scrum language can be introduced later, after the concepts are understood. Using more common descriptions at first will help everyone feel more comfortable with the road ahead.
If you’d like to learn more about the technical side of Janrain, please visit our Developer Portal.
This article was originally published by the Scrum Alliance.
Why customer experience is essential to (C)IAM success.
Ten years ago identity and access…
From the barista who knows exactly how sweet you like your daily nonfat, caramel macchiato to the…
According to IBM, poor data quality costs U.S. businesses $3.1 trillion annually. This is…