kanban

An Agile Hybrid Approach – What to Consider

Posted on by

an-agile-hybrid-approach-what-to-considerMany practitioners and project managers look toward creating an agile hybrid approach by doing a mish-mash of waterfall with agile methodologies. However, what we are going to look at are the different agile methodologies and the ones that are actually compatible with each other. It must be said, that for any team about to proceed with tailoring different agile components, it is something that should be done with expert practitioners who understand the pros and cons of adding more than one methodology into practice. It is advisable that a solid team of expert agile coaches and scrum masters are present on such a team so that the evolution and benefits can be implemented effectively and safely for the entire team.

Agile Frameworks Compatible in Creating a Hybrid Framework

1- Scrum

Most members of an agile team know agile by way of the Scrum framework, but what most have yet to see is that although it presents a solid framework for complex projects, it could use the help of other methodologies. What we can take from Scrum however, is the concept of building backlogs with work items that get listed in priority. The second automatic component is the importance of a Product Owner who actually owns that list and ensures that they represent what the stakeholders will expect. This is done through prioritization of the backlog for the rest of the team so that a potentially deliverable product is completed and accepted by the stakeholders by the end of each sprint.

2- Extreme Programming (XP)

From this methodology we can gather the best practices for the development team including Refactoring, Test Driven Development (TDD), continuous integration (CI) and collective ownership. What we tend to see in these practices are the concept of work process that is conducive to the flow and efficiency of the work being done.

3- Agile Modeling (AM)

This methodology is usually considered an effective addition to most of the other agile methodologies. It has mainly two components: Modeling and Documentation. The Modeling component encourages best practices such as Just Barely Good Enough (JBGE), Architecture Envisioning, Lookahead modeling, Active Stakeholder participation, and Model Storming among others. The Documentation aspect covers the necessity of documenting continuously (not to be understood as documenting excessively), document late, executable specifications, and single-source information.

4- Unified Process (UP)

Over the years the Unified Process has taken on many forms, mainly the Rational Unified Process (RUP) from which it derived directly and sometimes is mentioned interchangeably. However, other examples include OpenUP, and Agile Unified Process (AUP). What needs to be considered is that UP is not just a process but an actual framework. What makes it useful is that it’s highly customizable with characteristics covering an iterative and incremental development process, architecture centricity and risk focus. From this framework we get 4 phases that are used for creating a project, namely in the following order: Inception, Elaboration, Construction, and Transition. Much of what is used in the Disciplined Agile Delivery (DAD) framework has adopted this but DAD has also added to this.

5- Kanban

From the realm of Lean practices, we get Kanban. This method framework builds on the concept of Just-In-Time (JIT) at its base, but it has many tools that derive from it, one of them being the Kanban Board. The Lean aspect comes with the concept of limiting work in progress to prevent waste. Along with that comes the concept of visualization of progress. With the use of Kanban, the level of product quality becomes optimal since all areas of waste (Transport, Inventory, Motion, Waiting, Over production, Over processing, Defects, Skills) are removed. Along with that, the high level of visibility of progress that the development team is something that is of utmost importance. As most who have practiced Agile will see, the aspect of visibility is a very important characteristic to creating and maintaining team synergy.

There are certainly other methodologies that can be put in the mix, but it must be considered that tailoring an agile hybrid approach is an art, not a science. That is to say, if key components are added from one project to the next, it will likely not create the same results for every project. There are many other factors that come into play, and would not simply be a matter of methodologies used, but also the variation of players involved, that is certain to change the project landscape at any moment’s notice.

[Image courtesy of ratch0013 at FreeDigitalPhotos.net]

 

5 Healthy Workplace Habits by Using The Scrum Process Model

Posted on by

5-healthy-workplace-habits-by-using-the-scrum-process-modelThere are many ways to do work, and to be honest, not many people are taught how to create good or optimal workplace habits. That being the case, workplace dynamics can range from being a cesspool of toxic behavior and habits, to one that has an environment of the utmost respect for one another. The environment created in most workplaces is a cumulative result of individual behaviors happening at a given time, much like society, but only much more concentrated since we’re left to interact daily from morning until afternoon with our work colleagues.

The following factors, as part of the scrum process model, are found to reduce stress, anxiety and in turn increase workplace  motivation and productivity:

1- Intermediate Deadlines (The Sprint)

It has been shown that when work has no confinements and there is “no light at the end of the tunnel,” the level motivation steadily declines over time. Further to this, the likelihood of burnout and employee turnaround starts to become more and more apparent. The Sprint as a 2 to 4 week timebox that is meant to happen iteratively, gives a mini-project sense to accomplishing each round that expectedly gives a delivery of product. Intermediate deadlines in this case, tend to occur frequently and regularly give a sense of accomplishment and cyclical motivation.

2- Sense of Purpose (Sprint Planning, Sprint Goal)

When Sprint Planning takes place, there’s a chance for everyone on the team to set their sights on how much work can be estimated for the upcoming sprint timebox. As part of the Sprint Planning activity, a Sprint Goal is set by the Product Owner that enables all involved, the focus and vision as to what they will all being working toward by the end of the Sprint. Consequently if there is proper buy-in at the start with all sights on the sprint goal, it will give that sense of purpose that everyone can focus on and relate to for achievement.

3- Doing Things Better Every Time (Sprint Retrospective)

As most workplaces allow their employees to become complacent, and resulting in lack of performance feedback, the Sprint Retrospective allows for that time where everyone as a group can look at what were the great and no-so-great behaviors of the previous sprint. This sets the course for getting better on an iterative basis as this is done in each sprint. What some people don’t realize is the advantage of thinking of what to “stop doing” and what to “start doing” is already a two-fold way of taking on good habits. This is a bi-directional thought process, since most people typically think of improvement in one direction such as “just do things better” and leave out “what bad habits should I leave out of my routine.”

4- Great Support Network (Daily Scrum/Standup)

Everyone knows that an ongoing support network is a great positive factor. The daily scrum/standup allows for everyone to confirm what they were working on the previous day, and what they will accomplish for the remainder of the current day. The key part of team support for that day is when impediments and blockers are reported. This is a chance for everyone to chip in and see if there’s a way to resolve the blocker. This isn’t just the job for the Scrum Master, but also for the rest of the team. So the blocker announcement starts at the scrum meeting, but gets resolved outside of the meeting with the relevant members of the team, most likely those that are knowledgeable in the area of the impediment. Everyone else continues on their existing tasks to make sure productivity is not impeded.

5- Being Able to See Results  (Daily Scrum/Standup, Sprint Review, Sprint Retrospective, Sprint/Kanban Board)

The structure from which we have a sprint allows everyone to see results on a regular basis. Whether it’s on a daily basis (Scrum/Standup) or by sprint duration (Sprint Review, Sprint Retrospective). We are able to see and experience results on a very constant basis. Along with tools such as the sprint/kanban board that are high-touch/high-visibility in nature, allows for everyone to see progress and status as it happens.

On a Final Note…

It must be said, getting everyone aligned to proper workplace habits can come naturally to those who adopt the scrum process model. It’s not necessarily about having a process, but actually  having a positive attitude and confidence that it will work. Creating that momentum in your day-to-day, will likely come with resistance at all stages of development, but those who are on board, will quickly become visible to the organization and will certainly become the agile champions and leaders.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

 

How to Manage Epics as an Agile Tool in Planning

Posted on by

how-to-manage-epics-as-an-agile-tool-in-planningAs part of a large project, you may have a complex product to develop. Whether for intangible (software, games) or tangible (hardware, electronics), there is a need to structure your backlog by level of complexity and size. Although we typically do not go so far as creating Epics in all agile instances, they can prove to be a handy agile tool if created and used in an organized fashion.

The idea behind Epics are to create a sense of commonality between multiple user stories. It is important at this stage to be sure your agile team members are not using the terms for Epics interchangeably with other terms that could drive confusion in day-to-day communication. But along with this defined approach, all team roles (product owners, business analysts, scrum masters, developers, etc) should think of Epics structures and how they will be used going forward. Here we look at Epic examples in hierarchies for Features, Themes or Requirements.

Features in Epic Hierarchies

One way to look at an Epic is to identify it as the high-level feature. As an example we are referring to the physical features of a landing page on a website. It would have a header, footer, content, images, media, etc. With that you can further breakdown the characteristics with user stories, and then tasks to look like the following:

Epic(Feature) —> User Story —> Task(s)
Example: Header —> As user, I would be able to use a search bar to search the site content… —> Investigate Search Bar functionality

Themes in Epic Hierarchies

Epic —> Theme —> User Story —> Task(s)
Example: Landing Page —> Page Structure —-> As a user, I would see 3 columns… —> Create left column, Create right column, Create center column

Requirements in Epic Hierarchies

If you were developing a series of websites for instance, you would need to repeat a set of requirements for each website. In this case you would likely re-use the requirements as you start each website, and then vary those features. The following example would facilitate re-use of the requirements from one website to the next.

Epic(Requirement) —> Feature —> User Story —> Task(s)
Example: Website Landing Page —> Website Page Navigation —> As a user, I will be able to navigate to all site pages from the landing page… —> Create Navigation Bar

There is no definite way to use Epics, these are simply examples. The variations can be infinite and can vary from team to team, project to project, or product to product. But as we know that Epics are typically large user stories, and represent a level above the user story. One thing that needs to remain stable is that the agile team must agree to structure that makes sense for them.

Using Epics to Stay Organized

Using Epics as an agile tool to organize the stories, can enable easier overview of the different product components (features/requirements/themes). As the sprint backlog can list tasks to be developed by multiple agile working teams on different features at the same time, the overview of each Epic can help the Product Owner prioritize stories and interlinking dependencies with each other.

Another useful setup that helps in the structuring of swimlanes for your Sprint/Kankan boards is to have them created according to your Epics. This makes the horizontal divisions clear on the common groupings. It also adds another dimension to manage on your board, but it certainly would be helpful in larger sized projects.

The most important part in creating structures, is to keep it simple. If there is too much team discussion and confusion where everyone is lost in managing the structure, it means that it’s not simple or clear enough. Of course, if all else fails, keep in mind that Epics are not essential. If your team doesn’t see a need for them to exist in your agile product management scheme, just leave them out, as they might not be required due to your project not being as large or complex as originally thought.

[Image courtesy of Danilo Rizzuti at FreeDigitalPhotos.net]

10 Signs of Unsound Agile Individuals

Posted on by

Top 10 Signs of Unsound Agile IndividualsYou may not always notice at first, but you may come across certain individuals within agile product management circles who although they may consider themselves practicing agile principles, may in fact not be.

Here are a couple of tell-tale signs on how to identify unsound agile individuals, or get some indication that someone isn’t grasping agile as it is meant to be:

1 – They use the term agile to refer to a process

You may see this one as the most common. Where the fact that their development cycles involve the use of sprints, they interpret this as being agile. This is one of the most common reasons why misinformed management see agile as ineffective. Most software development managers and their teams will take certain aspects of agile, mainly in the form of an agile tool, and then try to explain to management that they are doing things in an agile project methodology. Due to the lack of overall understanding of what agile is, this inevitably leads to failure, and the creates the misconception.

2 – They say agile for Kanban/Scrum/XP/Lean Interchangeably

Rather than referring to the synthesis of methods, processes, practices, principles and ideologies of agile solutions, some individuals seem to identify with only one agile practice, i.e. being knowledgeable in Scrum, they speak in terms of Scrum in itself as what it means to be agile. Certainly practicing scrum would be a step in the right direction, but it’s not all there is.

3 – They have a command-and-control approach to management

When someone uses their work title as the only form of authorization and direction to make decisions, you will inevitably see lack of innovation and creativity from the teams they were meant to lead. Micromanaging is counter-intuitive to the servant-leadership approach that agile promotes.

4 – They would rather work alone

You may notice those that like to just do things on their own, and see it at the most effective way to get things done. Agile is not accomplished in a bubble and it requires the full spectrum of agile team roles and the synergy that it provides.

5 – They prefer low-effective forms of communication

If the person you are speaking to prefers regular use of emails, texts, and IMs as their principle forms of communication it will short change the entire chain of communication. The reason for this is that most of those messages lose the original intent they are meant to convey. When we consider that 7% of all communication is words, 55% visual, and 38% vocal, we can see that there are some serious limitations to just communicating in a written form.

6 – They think that agile alone guarantees project success

This comes from many misconceptions, but mainly it principally comes from limited depth in understanding how to become agile. Some people like to throw around agile as a plan for success because they read about it in an article, when in fact they do not realize that using it as a “buzzword” for a solution does not mean there would be the proper steps taken to succeed.

7 – They expect others to “do-as-they-say”, not “do-as-they-do”

This is similar to command and control, but goes beyond structure. We are referring principally to when you have someone who likes to do things contrary to what they’ve recommended or said. Also where they tend to see a sense of impunity, bullying and envy among teammates is along the same lines of where someone has lost the grasp of what it means to be a part of an agile working team.

8 – They do a lot of talking and not enough listening

When you see that someone is regularly the only one talking or interrupting in a conversation, this means they are likely unable or unwilling to be active listeners. This likely could be interpreted to mean that they don’t value your opinion and would rather be in a position of influence rather than compromise or collaboration. This is not to be confused with active participation. If someone is asking relevant questions they are likely listening very closely and want to hear more about what others have to offer in the conversation.

9 – They judge unsparingly

We’ve all heard of tough love, but when you have someone who persistently rants and gives negative, unconstructive criticism it puts a halt on all team synergy. Nobody wants to contribute in an environment where they will be judged.

10 – They have low EI (Emotional Intelligence)

Many people are stuck on having the most knowledge, the most expertise, the most qualifications. All of that means nothing if you do not have a personable way to approach those you interact with. For someone having a low EI means that there’s a lack in ability to distinguish between their own emotions and those of others. This makes communication and trust (among other things), very hard to accomplish. In the presence of someone with low EI, most will interpret that person’s actions as being negligent, narcissistic, arrogant, or unsympathetic.

Giving these examples will hopefully shed some light on the types of signs where others who would likely present themselves as agile mindset individuals. This is not to be used as a means to single out those types of individuals to be banned from such teams, however we do encourage regular agile coaching, training, and courses to help educate them about the impact they take on their overall environment. It is difficult to find people knowledgeable in all areas of agile, as most pick their area of comfort and become highly skilled practitioners in their specific area of expertise.

[Image courtesy of iosphere at FreeDigitalPhotos.net]