Welcome to The Agile Times!

Agiletimes_Logo_square_webpageOn our site you can find a series of expert opinions, advice on Agile insights, book reviews, and software usage tips, as well as training certifications and recommendations. Bookmark us now and join our Newsletter for regular (but not overly annoying) updates. 


Feel free to join us at our other social sites:
Facebook_logo   twitter-logo    linkedin


August-September 2017 – Book of the Month

Improvisation. The mere mention of the word makes many people quake with fear at the prospect of chaos and uncertainty. The fact is, though, human beings are improvising almost every minute of their lives it is more natural, and more filled with possibility, than you might imagine.

On stage, improvisational actors use simple rules, collaborative principles, and game constraints to build unscripted yet intriguing storylines. This book explores how those same simple rules and principles can help agile teams collaborate more effectively and how purposefully working within constraints can unlock creativity.

Inside, you ll find over 50 techniques and improv games tailored for agile teams, complete with step-by-step instructions. These games are based on five different principles of improvisational theatre:

SAFETY: how accepting failure is essential to discovery
SPONTANEITY: how to increase the flow of ideas
STORYTELLING: how narratives help teams relate to their customers and end users
STATUS: how adjusting personal behaviour can encourage collaboration
SENSITIVITY: how to become more fully engaged with fellow team members

Improv-ing Agile Teams: Using Constraints to Unlock Creativity
Author: Paul Goddard


Warning! Parkingson’s Law in Agile Projects

One cannot avoid unseen forces in effect when agile in place. That said, when practicing Agile you must be aware of the “Laws” at work. We’re not necessarily talking about the ones that bring about the police, judge and jury if you break them. When looking at Parkinson’s Law, we’re talking about a law that you can’t avoid whether you like it or not. 

What Is Parkinson’s Law? And How it Works

Parkinson’s Law is all around us, and it’s part of our everyday lives, but since we find it to be a natural progression of what is constant in our day-to-day, we think nothing of it. So it’s time to wake up! What about Parkinson’s Law? Well it states that “work expands so as to fill the time available for its completion.” That is to say, we usually think of estimating work (in whatever form you decide), to the extent that we know about the available resources. If you were asked to go fill a cup of coffee for someone, or yourself for that matter, would you be likely to fill it to the top, or just halfway. Sure we can think of the times we would fill it halfway, but more often than not, we fill it to the top. So we’re not saying Parkinson’s Law is an absolute or that it happens 100% of the time, but it does certainly happen often.

How Can You Spot Parkinson’s Law at Work?

avoiding-parkingsons-law-agileUsually when we estimate during planning sessions, we may be lead to fill up the time we have to do something, with the time we have available. So let’s think of this on 2 levels. In sprint planning we naturally fill in the Sprint with the story points based on our average velocities from previous sprints. Now that’s where Parkinson’s Law works well. And that’s actually why we use story points, to remove the concept of time, and falling into traps, not just Parkinson’s Law. But say for instance, someone asked you to estimate a Story (or Use Case) in real time, and imagine that you were somewhat influenced previously (or at that very session), where someone said in low-key that you had about 3 days to do it. It may very well take 2 days to complete the work, but are you being rational at that point? Or are you going to really take some time to figure out how long it may actually take? Any task, no matter how simple or compact, deserves a fresh set of thoughts and ideas to assess it’s level of complexity. Reason being, you wouldn’t want to over (or under) estimate a task if it truly wasn’t the time it could’ve actually taken.

What Are the Consequences?

Assume you estimated every task you had with what your colleagues told you is the “standard.” You could very well just go with the “standard” times, or better yet you may give yourself the excuse that you didn’t have the time to run through the actual requirement, or the task seems so simple, it shouldn’t take longer than the “standard.” Think about what this means with regard to the overall value of a project. The concept behind which sprint planning, depends on your flexing the metaphorical estimation muscles. The more you practice, the better you will become at being increasingly accurate. With unrealistic estimates, you may actually inflate budgets, and the perception of waste will be greatly increased, and the level of competitiveness drops. Many teams can fall victim with this Parkinson’s Law at work, when many tasks that shouldn’t take very long, end up being logged with double or triple the time it really took. You may be able to get away with it sometimes, but what if your client isn’t that naive?


[Image courtesy of stockimages at FreeDigitalPhotos.net]

June 2017 – Book of the Month

In understanding methodologies and agile project management, we look at the different techniques in which you can successfully develop management skills. As you know, it is quite important to adopt a multifaceted approach when it comes to management, to get your job done in a facile manner.

Agile methodology is a multifaceted approach that finds its application in many different fields and can be considered an umbrella concept. Right from engineering to IT to business management, there are many areas where one can effectively apply the ideologies of agile management. Once you go through the book, you will understand how easy it is for you to adopt and utilize it to enhance your business.

The agile management technique focuses on four main aspects, namely – effective communication with clients/parties, delivering a work application, collaborating with clients and changing up the scope of work.

All of these need to be controlled and managed in order to enhance productivity. That is exactly where this book comes into play.

In the course of this book, you will learn how to:

  • Understanding the iterative learning process
  • Learning about the agile software development techniques
  • The scope of management
  • Meaning and features of agile manifesto
  • Dynamic system development model and its applications
  • The phases of the Atern project
  • Understanding of the scrum theory
  • Sprint reviews and sprint retrospectives
  • Service designs and transitions
  • Service operations
  • Lean development principles
  • Operational level management techniques
  • Steps to enhance focus

Agile management basically focuses on enhancing communication within the organizational structure to ensure that you remain with free flowing ideologies. It is a good way to increase your productivity while managing your work environment. The book focuses on understanding each and every element by breaking it down to the simplest form. The concepts are explained in such a way that they allow you to implement them in your work life. You can go through the concepts in detail to understand each and every aspect of it. There is no limit to its application and you can mold it into any shape or form of your choice. You can pass a copy of the book to all your employees so that they can understand what it takes to partake in agile management of business. You can also consider holding a seminar or a book reading session where everybody can interpret their ideologies in their own way.

Using the information provided in the book, you can implement agile management in your day-to-day life; whether it is work or personal life. So what are you waiting for – start reading right away!

Agile Project Management: A Complete Beginner’s Guide To Agile Project Management
Authors: Marcus Ries, Diana Summers


May 2017 – Book of the Month

This book will show you how by using Agile Methods in you Projects you will not have to worry about the delays in the deliverance of your projects because all the work is done is iterations and among these iterations, testing of the product is conducted due to which if any bugs are found, they are removed immediately and if the stakeholder demands any change, it can be provided to him.

This book is about the Agile Project Management. It is basically the guide for beginners. Those who have no or very little idea about what Agile is and how it is beneficial for your Projects, can take a lot of help from this book. Most of the technical words and a bit of history is mentioned in easy and compatible words.

What Scrum, Sprint and Agile is, how Agile is better than the Traditional Project Method, what are the top Software of Project Management with pros and cons of some and what Agile Manifesto is on the basis of which this whole Agile is developed and what is the framework on which Agile Methods can be used, all are discussed in this guide.

Here is a preview of what you’ll learn:

1.Introduction to Agile and Scrum
2.Agile versus Traditional Project Management
3.Agile Manifesto
4.Top Agile Management Software
5.Getting Started by Implementing Scrum

Agile Project Management: The Ultimate Guide To Agile Project Management And Software Development – Plus Tips & Tricks For Implementing Scrum!
Author: Henry Hayes

April 2017 – Book of the Month

Ethan, the newly appointed Transformation Team Leader at VeraComm Systems—a large product development organization—finds himself in the middle of violent action: the company has failed to cope with the increasing complexities of building competitive communications solutions and is rapidly losing market share. Caught between a traditional approach to program and portfolio management, and half-baked Agile methods at the team level, he struggles to help his company find a way out. Faced with a nearly impossible quest, he attends a conference desperately seeking a solution. There he finds a glimpse of hope—a method that applies the notion of Agility at a much higher scale. Inspired by this discovery, Ethan charges into action, launching the rollout of a new method at his company. But in no time, he runs into a brick wall which puts the rollout, and his own career, in grave danger. He comes to realize that the basic culture and his enterprise’s way of thinking are its biggest impediments to success. His quest leads him to understand that his own mindset is also part of the problem….

The reader will be pulled into the exciting action unfolding as Ethan leads his organization towards enterprise agility. Fictional, but based on a broad range of real-life implementations, this novel by Alex Yakyma provides a war chest of techniques and tools to support large-scale rollouts of Lean and Agile methods.

The Rollout: A Novel about Leadership and Building a Lean-Agile Enterprise with SAFe®
Author: Alex Yakyma

March 2017 – Book of the Month

As contrary as it sounds, “planning” — as we traditionally understand the term–can be the worst thing a company can do. Consider that volatile weather events disrupt trusted supply chains, markets, and promised delivery schedules. Ever-shifting geo-political tensions, as well as internal political upheaval within U.S. and global governments, derail long-planned new ventures. Technology failures block opportunities. Competitors suddenly change their product or release date; your team cannot meet the pace of innovations in your market niche, leaving you sidelined. There are myriad ways in the current business environment for a company’s well-considered business plans to go awry.  Most business schools continue to prepare managers to be effective in stable and predictable environments, conditions that, if they ever existed at all, are long gone.

The Agility Shift shows business leaders exactly how to make the radical mindset and strategy shift necessary to create an agile, entrepreneurial organization that can innovate and thrive in complex, ever-changing contexts. As author Pamela Meyer explains, there is much more involved than a reconfiguration of the org chart and job descriptions. It requires relinquishing the illusion of control at the very foundation of most management training and business practice. Despite most leaders’ approaches, “Agility is not simply accelerated planning.”  Unlike many agility books on the market, The Agility Shift provides specific, actionable strategies and tactics for leaders at all levels of the organization to put into practice immediately to improve agility and achieve results.

Agility Shift: Creating Agile and Effective Leaders, Teams, and Organizations
Author: Pamela Meyer



February 2017 – Book of the Month

Projects will soon be managed with a hybrid of Agile and traditional Waterfall processes. This highly instructive guide covers what Agile is, and how and when it is appropriate to blend it into your projects. Agile Practices for Waterfall Projects will help new and experienced project managers, stakeholders, and students proactively prepare for and ensure their future success. It also explains all the terms and concepts contained in the PMI Agile Certified Practitioner (PMI-ACP) exam.

Key Features:

–Presents specific, workable methods to add Agile to your projects while preserving your investment of time and development in traditional Waterfall processes
–Uses interactive tools to help readers understand, experience, and discover techniques to blend Agile with Waterfall processes in the right amount for each project
–Describes how to work with the major Agile methodology teams, and ways to merge the teams, reports, documents, metrics, tools, and meetings between Agile and Waterfall teams
–WAV offers a downloadable Agile Evaluator, Agile Evaluator Checklist, Agile Evaluator Sample Results, Planning Poker Cards, Story Card Templates, and a PMI-ACP Practice Exam

Agile Practices for Waterfall Projects: Shifting Processes for Competitive Advantage
Author: Barbee Davis

agile-practices-for-waterfall

The Importance of Time Completed and Time Remaining in Estimations

importance-of-estimates-time-completed-time-remaining/One of the first things many team members on Agile projects lose sight of is the importance of tracking their time spent on their tasks identified in their Backlog Item. Whether it’s a User Story, Sub-Task, Enhancement, etc., logging hours spent is of absolute importance to make sure further Sprint burn-downs, velocity, and estimates will continue to reflect increasing accuracy. The tendency of some teams is to use their Backlog Items (in either of the forms mentioned above), as a scope tracker. However, time-tracking on a daily basis is of absolute importance.

How Your Hours Should Really be Logged

Once a backlog item has been completed, only then do team members log their hours, and it most likely ends up being the hours set in the original estimates. Not only is it best practice to log hours spent on your backlog items on a daily basis, but also to re-assess what the remaining hours are. Just because an item was estimated to take 16 hours, and you performed 8 hours so far, it does not mean 8 hours remain. Sure it would seem logical that it would come down to a simple mathematical equation, but it’s truly not what is meant by “Time Remaining!” So what should be put in Time Remaining? It’s really about what should be required to complete the task at the moment of logging your time mid-course. What that means in our previous example; if you logged 8 hours for a task that was originally estimated at 16 hours, you may come to realize, there’s only 4 hours left. It’s as if you are re-estimating or re-assessing what is left to do. A number that does not match what was originally estimated, is perfectly fine either from a downward estimate or an upward one (assuming it’s done correctly of course!). This is by far the best way to know if original estimates were done accurately, and gives team members a gauge on whether those estimates continue to be assessed correctly in later sprints. Better yet, if needed, the variance of estimation accuracy can be calculated as well.

When Time Remaining is Not Taken Seriously

The problem arises when developers mark down remaining estimates as a straight-line mathematical equation, since it would imply that all original estimates were done properly, and makes it impossible to weed out the estimation imperfections during Sprint Planning from Sprint to Sprint. The other issue that may happen is that there could be a skew in estimations since some developers will take their time to complete a task (if they see that they’ve completed it early), and then hurry their task, or worse, bust the estimates if the task was underestimated. From there, it may escalate to having only underestimated tasks as being incorrectly estimated. What that gives is a mix of underestimated, and on-time estimates. As you can see, when the hours are totaled up for that sprint, the skewed results give an impression that generally all tasks were underestimated, and the lack of transparency will make the team draw separate conclusions. This also affects your burn-down charts and interpretation of velocity, all the while the cycle of trust within the team is broken.

How This Helps Continuous Improvement

Seeing the above situation in a different light, if you were on a trip where the original travel time was supposed to be 10 hours, only to find out the ride is shorter than expected, you would probably want to know, right? The same would apply if it would be longer than expected. To make the point clearer, your expectations, and that of others depend on the transparency of what remains to be done on any development effort. This aids efforts for future estimations and weeds out any further potential to be disappointed.

The next time you may be faced with a seemingly obvious question “How much time is remaining?” it may need to be seen as “How much time is needed to complete the task?” It’s not just a simple math calculation. Remember that estimates are called “estimates” because there is a chance that they will not be “accurate.” Having those numbers accurately represent “time remaining” allows for the estimation process to get better and better, as the team looks back in retrospect and compares their estimations for future Sprint Planning sessions.


 [Image courtesy of lekkyjustdoit at FreeDigitalPhotos.net]

December 2016 – Book of the Month

Are you getting all that you hoped and expected from your Agile software development process? If not, it might be because your product governance processes are in conflict. As a director of a Program Management Office I’ve seen that by making a few simple but critical changes to your process you will reduce the time wasted on products that will never get built, make better product choices, and enjoy better relationships between your managers and software development teams. After reading Succeeding with Agile Governance, you will know the importance of more Agile-friendly approaches to governance and will be equipped with the knowledge and tools to implement effective Agile governance. You will know to:

  1. Plan using only the appropriate level of data available, elaborate, and change the plan as assumptions change.
  2. Be disciplined about when and how to make decisions.
  3. Separate accountability for solutions and requirements from accountability for the market problems and business needs.

Succeeding with Agile Governance: The Agile PMO
Author: Paul Osborn

succeeding-with-agile-gov
BUYNOW_BUTTON

 

Agile IS NOT Scrum!

agile-is-not-scrumThere are certainly many misconceptions that occur with having to implement agility within the organization. The issue becomes even more compounded when non-agile practitioners speculate about what Agile is or for that matter what their idea of what it should be. In our example, this kind of speculation can present a sort of revolving door phenomenon whereby those who are familiar with Scrum, use it to refer to Agile interchangeably. Admittedly, Scrum is a large part of Agile when referring to it holistically, but Agile is not Scrum. However, we can derive some values from Scrum and say that they are synonymous with Agile values. What tends to happen is that many people believe that if they are doing Scrum, then automatically they are Agile. There’s a very fine line to that supposition, but it’s not always entirely true.

Part Of The Whole Doesn’t Necessarily Mean You Are All Of The Whole

For the most part, implementing a part of the whole doesn’t necessarily mean you are all of the whole. As an example we can use the idea of electricity. If some parts of a car (i.e. radio, window system, pumps, battery) are electric, would you say that your car is an “electric” car? Not likely. Even when we do refer to electric cars that are motorized by electric power cells alone, the car isn’t entirely electric per se. This comparison although not an exact representation of the differences in Agile or Scrum, hopefully can give you the level of complexity in the assumption of either one for another.

Agile Is Not Just A Process

For further clarity, there are other mechanisms of Agile in perspective, there is also a mindset and value-driven aspects that should be accompanied with it, not just a process. There’s also other methodologies and processes that can be included or can be complimentary to Scrum (i.e. XP, Kanban, TDD, ATDD) that make a more solid Agile implementation possible. That is not to say that it’s an “all-or-nothing” situation. Further to this we have what is considered to be the Agile guidelines, also known as the Agile Manifesto consisting of 4 values and 12 principles. When speculation and discussion occurs about what Agile really is, very seldom does the conversation include what is mentioned in the manifesto. However, more often, the concept of implementing a Scrum process does. This is where the clarification about those assumptions or beliefs, is very important to distinguish before it’s too late, whereby the decision takes place and is built on a preconceived false notion of Agile.

Agile Expectation And Implementation

Getting the above points out in the open early is not only to assure successful Agile expectation and implementation, but also to bring a more positive light to what can sometimes bring “failures-as-fact.” By that we mean that there are many who have attempted implementing Agile in the workplace, and used a “not-so-complete” method or process into effect. That is to say, they thought they were putting an Agile methodology (or in certain cases what they thought was Agile) in place, then saw it fail, and then concluded “Agile doesn’t work” despite the other flaws.  There are certainly instances where Agile really doesn’t work, or perhaps it isn’t the best solution for your organization, politics and bureaucracy aside. Agile isn’t the cure-all solution to all your organizational woes but can definitely be more fun! Even when it’s not a good match for the organization, not implementing Agile is perfectly fine, it’s not a must, and further to that, it’s not a religion (although it sometimes is perceived as such).

5 Inefficient Communication Habits That Cause Waste

5-inefficient-communication-habits-that-cause-wasteIt’s not hard to believe, we have a tendency to waste a lot of time communicating whether it be through face-to-face, talking, texting, emailing, or chatting online. The problem with that is that everyone’s bad habits can get the best of you whether you like it or not. Have you ever gotten that email where you can’t decipher whether it was a request? some sort of prank? or yet something absolutely serious?

We all know the situation could be better, as many do in today’s day-to-day lifestyles, people claim they no longer have time for the simpler things in life, just relaxing or taking the time to do something truly for themselves. Below we’ve identified some of the bad habits that you may want to avoid, and for your own sake, be able to identify from other before you get pulled unnecessarily into someone else’s trap:

1. Putting “Quick Question” in the Email Subject Heading

The intent of someone who puts “Quick Question” in the subject heading of an email is certainly obvious: they have a need to resolve a question quickly. The problem is that the intent is a setup for one’s own need to get immediate gratification at the receiver’s expense. The question you have to ask yourself is how “quick” does a question need to be answered, and is it worth stopping what you are currently doing only to be distracted by someone else’s supposed “quick” needs. You may need to consider that there are times when someone’s need for a quick answer is valid i.e. a life-or-death emergency situation, but if you are seeing this type of email regularly coming from the same person, it indicates that they are certainly not taking their own time to get a little more organized. Then ask yourself this: Would you distract yourself from someone’s “quick” question, if they can’t get themselves organized? We are tempted to say “yes” if it was a situation where it was our customer, after all they are paying for it. Or are they? In the grand scheme of things you are doing both yourself and the customer a disservice. First, they will never learn how to organize themselves with prioritized efficiency, and second it will always be to your (and your company’s) demise as you keep your phone or emails rolling in for around-the-clock response times that weren’t necessarily part of the contract.

2. Calling With No Advance Warning About A Complex Question [something you couldn’t possibly have a quick answer to anyway]

We all know, receiving a call from someone in need is something urgent, should be taken seriously. However, you should be cautious about the intent of those who call others about a complex question that needs to be answered on the spot. The quick answer to that is “Can I call you back with the answer?” If they don’t want to give you the time to research and respond, then you know you may be facing issues about your response later on. The other way to prevent any misunderstandings is to ask that they send you a followup email outlining all issues in the question that needs to be addressed. Note, we are referring to a “complex” question. Failure to get this outlined in writing could present some issues down the road, as you run the risk of having to address “unmentioned” questions that they “thought” they asked you during the call.

3. Requesting Something That Could Easily Be Answered From An Online Search

Unfortunately, we all get this a little too often. In the age of Google, we still tend to get even those seemingly difficult (and more often simple) questions that can be easily answered by just looking it up online. As you may have guessed so far, we are referring mainly to the question “Can I answer this on my own?” Forcing someone (whether directly or indirectly) to answer a question that can so easily be answered is not only going to frustrate them, it could potentially cause you to not be taken seriously by peers. It could potentially create the “boy who cried wolf” scenario.

4. Sending Really Long Emails

Sometimes it’s necessary, but beware of the really long email. Unless you are sending out a newsletter or occasional email with reference to updates within your department, a really long email is what can cause many to just ignore right there and then, and for the next time around. We often forget that an email was meant to send a message, not a book… On this topic we are mainly concerned about quality not quantity. Many write their emails while restating the same issue many different ways throughout the body of the message. This only frustrates the reader while forcing them to read to get to the bottom of it, then only to notice they wasted more time reading it than it was worth. If you can’t get your message across in fewer words, then others may not see the point in reading your email. A good way to avoid this is re-read your message before sending it. If you find that you get bored or confused by your own email, consider that many others will certainly feel the same.

5. Sending Text Messages Even Though They Don’t Get An Immediate Response

The texting phenomena is at full stream. We all seem to do it, sometimes while driving, walking, or talking (if you do then STOP!!!). Let’s admit it, we all feel like it’s ok to text no matter what other activity is going on around us. The problem is that we don’t realize that we are creating a norm that we feel is ok, while many others (the silent majority), feel is inappropriate to do. Among these, is sending multiple consecutive messages to your peers while they may not be able to respond immediately, or better yet, they may not even see them by the end of the day. The last thing you want is having someone catching up with a backlog of messages, as the sender is rambling about something that couldn’t wait for input from the receiver in the first place. If that tends to be the case, a phone call may be a reasonably better alternative.

While the topics in the list above may seem obvious, there are many who don’t realize the auto-pilot mode that technology has all put us in. That is not to say that technology is bad. But what it does say is that we need to take it a lot more seriously, and more importantly we need to consider how we are affecting others in the process. If you are not taking your own habits (and time) seriously, you can’t expect others to do the same.

[Image courtesy of marcolm at FreeDigitalPhotos.net]

November 2016 – Book of the Month

If you want to understand how to lead a Continuous Delivery or DevOps transformation in your company, there’s no better book than this. Concise, practical, and based on hard-won executive experience, this book is essential reading for every IT executive. (Jez Humble, VP, Chef)

This book goes beyond theory and deeply into reality-based application. (Greg Nicastro, EVP Product Development and SaaS Operations, Veracode)

It’s long past the time when executives who are looking for better performance from software development can expect an “Agile transformation” to solve their problems. Today’s wise executive will know enough about the underlying principles of software systems to ask the right questions and make sure that their organization is solving the right problems. That’s where this book comes in—it contains just enough theory to inform executives about critical issues and just enough detail to clarify what’s important and why. (Mary Poppendieck, Author of The Lean Mindset and the Lean Software Development series)

Leading the Transformation is a critical asset for any leadership in a large development environment seeking to transform the organization from the swamp of restriction to the freeway of efficient delivery. The book provides real-life data and solid advice for any leader embarking on or in the middle of an enterprise delivery transformation. (Lance Sleeper, Senior Manager of Operations, American Airlines)

Before you undertake a major change in your development process, you want to learn from people who have gone before you. Gary and Tommy draw on their experience to prepare you on how to plan and what to expect as you roll out Agile/DevOps methodology in your enterprise. Reading this book, I learnt valuable lessons on planning a scaled-out Agile transformation and what signposts to look for along the way as we embarked on the transformation journey at Cisco. (Vinod Peris, VP Engineering, Routing & Optical, Cisco)

Leading the Transformation: Applying Agile and DevOps Principles at Scale

Authors: Gary Gruver, Tommy Mouser

leading-the-transformation
BUYNOW_BUTTON

How Osmotic Communication Uses The Subconscious

osmotic-communication-uses-the-subconsciousWhile the practice of agile requires a “Caves and Common” setup of teams, there is a reason for it. Mainly it’s to make sure communication is ongoing and regular. This requires a specific setup of office equipment and overall layout within the workplace. The “Caves” aspect refers to a place where some team members have the occasional place or space to work alone for a short or brief period of time, while “Common” is the area where most team members spend their time with the rest of their team for the majority of time in their day.

The Importance of Closeness Among Team Members

Agile practitioners would agree Osmotic communication takes place in most part within the “Common” space as everyone is communicating without barriers whereby conversations and discussions occur freely. The principle behind osmotic transmission and absorption of team members’ conversations implies that we acquire knowledge even if we are not an active participant in any particular conversation. Much like a song playing in the background, even if you don’t know the name of the song, if heard regularly over time, you may just be able to know the melody or lyrics without even trying to memorize them. How this actually is made possible is explained through the way our minds work on a subconscious level. It can be compared to a radio that is always on while the antenna is picking up frequencies at all times.

Much of what we do throughout the day, our daily routines, product purchases, learning habits, and inner thoughts are a result of our subconscious taking over very important aspects of our lives. Although it’s not easily explained, osmotic communication works on a highly metaphysical level. It provides a collective result, a lot of what teamwork provides only when they are in the same location, and not otherwise. This is mainly why the success of an agile team should not be given credit to any one particular member, but rather the collective effort of the entire team.

Osmotic Communication Effectiveness

The key idea behind making osmotic communication effective however, is that the communication should be within hearing distance of any or all team members on a regular basis. Without that, the knowledge sharing and subliminal absorption aspect gets chopped up. Using the radio frequency example, it’s similar to getting only some channels but not all, or a channel with a lot of static. This is how the subconscious mind works, it’s always on and absorbing without effort. It’s important when considering the physical team’s layout, especially in today’s work environment as many teams are known to be located remotely from each other, or with specific members working alone but connected online.

It’s no secret, a team that works together in the same physical space will communicate more efficiently either because of their added ability to listen in to each other’s conversations as well as read their body language. Compare this to a team whose majority of members are located remotely, there’s a big loss on the quality of communication. It becomes increasingly difficult to know if someone is actually being sarcastic or serious without having to see their facial expressions or body language. This is why conflict created among remote members for any particular team could escalate very quickly. They couldn’t possibly be (or become) an agile team with that factor to overcome.

[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]

October 2016 – Book of the Month

Captured for the first time in print, the SAFe body of knowledge is now available as a handy desktop reference to help you accomplish your mission of building better software and systems. Inside, you’ll find complete coverage of what has, until now, only been available online at scaledagileframework.com. The SAFe knowledge base was developed from real-world field experience and provides proven success patterns for implementing Lean-Agile software and systems development at enterprise scale. This book provides comprehensive guidance for work at the enterprise Portfolio, Value Stream, Program, and Team levels, including the various roles, activities, and artifacts that constitute the Framework, along with the foundational elements of values, mindset, principles, and practices.

Education & Training Key to Success

The practice of SAFe is spreading rapidly throughout the world. The majority of Fortune 100 U.S. companies have certified SAFe practitioners and consultants, as do an increasing percentage of the Global 1000 enterprises. Case study results–visit scaledagileframework.com/case-studies–typically include:

  • 20—50% increase in productivity
  • 50%+ increases in quality
  • 30—75% faster time to market
  • Measurable increases in employee engagement and job satisfaction

With results like these, the demand from enterprises seeking SAFe expertise is accelerating at a dramatic rate. Successful implementations may vary in context, but share a common attribute: a workforce well trained and educated in SAFe practices. This book–along with authorized training and certification–will help you understand how to maximize the value of your role within a SAFe organization. The result is greater alignment, visibility, improved performance throughout the enterprise, and ultimately better outcomes for the business.

SAFe® 4.0 Reference Guide: Scaled Agile Framework® for Lean Software and Systems Engineering

Author: Dean Leffingwell

safe_4-0_reference_guide
BUYNOW_BUTTON

Major Hurdles to Agile Adoption in Government Organizations

major-hurdles-agile-adoption-government-organizationsDespite what you’ve heard on the news about the federal debt, many federal, state, and local government agency budgets have been flat or declining for several years. Add in inflation and other cost increases, and these agencies are constantly being asked to do more with less. For the IT departments, this surely means they’ve made the transition to lean, mean, Agile teams, right? Well, no. But there are some good reasons for that.

Responsible Spending and Risk-Aversion

Government organizations usually have budgets that are determined by politicians and other actors outside the agency itself. Unlike companies that can expand budgets through increased revenue and profitability, government agencies need to justify budget requests by showing they have a responsible track record deploying their budget to meet their mission.

Tax payers don’t want the government making reckless decisions with their money. As a result, government organizations routinely make decisions that can be justified as responsible, risk-averse, or “safe” – even if those decisions are not the most efficient or cost-effective. I’ve heard it said that nobody has ever fired a government employee for using Microsoft Project on an IT initiative. In an environment like that,  a half-century old methodology like Waterfall – or a century old tool like Gantt charts – would be seen as preferable to newer methodologies that are not well understood to business or political stakeholders.

Delivery Dates vs. Sprint Cycles

Government IT solutions and systems are often the result of new laws or regulations, and have a defined time period in which they must be implemented after the new law is passed. Just like the adage, “requirements may be vague, but the software will be specific,” laws may be vague, but the regulations must be specific, and the software that implements them must be even more specific. Elements like complex business logic and multiple system interfaces cause managers and business stakeholders to ask for lots of documentation to prove that the system was built correctly.

When a new law mandates implementation by a specific date it creates an anchoring effect, that the system needs to be “done” by that date. Briefing senior government officials or even legislators on sprint velocity and burn rates is a much bigger challenge than providing dates and percentages. Even if, in the end, delivering the most valuable 80% of a solution on time should be preferable to delivering 100% of a system after a 1-2 year delay.

Software and Tools

Another reason no one in government ever got in trouble for managing an IT project with Microsoft Project is because it is already on the list of pre-approved software for use that nearly every agency maintains, in one form or another. Hardware and infrastructure requirements are a common consideration, as are licensing costs. But security concerns are an increasingly big reason why software on pre-approved lists keeps getting used instead of newer or better products being adopted.

Getting software tools approved for use at a federal agency means completing a thick stack of paperwork. It also requires a champion to spearhead the process, work with Help Desks on administration and conducting training. This means longer-term commitments to tools than in the private sector, and that larger companies with established products get used more often.

End User vs. Customer

Until recently, most end users of government IT systems were employees of that agency, so there was little conflict in seeing the end-user as an internal customer. As the internet has proliferated, more businesses and individuals are interacting directly with government IT systems: submitting applications and appeals, self-registering or updating information, or just searching for general information on a government website or portal. These external end users, or government customers, present a unique tension when designing systems for them.

While “the customer is always right” is a great motto for many private businesses, government agencies need to walk a fine line with that approach. They run the risk being too accommodating or “too cozy” with the people and businesses they regulate, and can erode trust that the government agency can regulate or monitor effectively.

Tight budgets, pre-defined timelines, and the need for some agencies to keep end users at arm’s length make it easy to de-emphasize agile principles like personas, end user demos, and usability sessions.


Contributing Author

David Pradko is a project manager and certified business analyst, who has worked with over a dozen government agencies to design and implement IT solutions. He as also appeared at the IIBADC’s Business Analysis Development Day and on Federal Tech Talk radio to discuss Agile in the federal government.

You can follow David on Twitter at @DPradko


[Image courtesy of Sira Anamwong at FreeDigitalPhotos.net]

NEW! The Agile Times Now Accepting Guest Expert Articles!

The Agile Times review committee is now open to article submissions by guest experts.

ID-10049433Please note that there will be limitations to what can be posted, and it may be reviewed and edited before being published on our site.

If you feel like you have some valuable insight and tips based on Agile related activities, this is your chance to share with our viewers. For more details, and to confirm interest in submitting your article, please go to our Submit page.
[Image courtesy of photostock at FreeDigitalPhotos.net]

September 2016 – Book of the Month

From Sharon L. Bowman, the author of the best-selling The Ten-Minute Trainer, comes the dynamic new book, Training from the BACK of the Room! This innovative resource introduces 65 training strategies that are guaranteed to deliver outstanding training results no matter what the topic, group, or learning environment may be. Now, trainers can replace the traditional “Trainers talk; learners listen” paradigm with a radical new model for designing and delivering instruction: “When learners talk and teach, they learn.”

The author’s four-step instructional design and delivery process involves learners every step of the way. Designed to be user-friendly, Training from the BACK of the Room! is filled with definitions, descriptions, and practical training strategies for each of the 4 Cs:

Connections—Fifteen opening activities that connect learners to the topic, to each other, and to what they want and need to learn.

Concepts—Twenty strategies that engage and involve learners during the lecture or “direct instruction” training segment.

Concrete Practice—Fifteen strategies in which learners actively review content and practice skills.

Conclusions—Fifteen learner-led summaries, evaluations, and celebration activities.

In addition, the book offers “nice-to-know” information that will add to what you have learned: the secret about adult learning theory, a new way to write learning outcomes, The World Cafe, tips for interactive e-learning, and other useful resources to expand your learning adventure.

Training From the Back of the Room!: 65 Ways to Step Aside and Let Them Learn

Author: Sharon L. Bowman

From_the_back_of_room
BUYNOW_BUTTON

Agile Antipatterns: The Dangers of Groupthink

agile-antipatterns-dangers-groupthinkAs agile practitioners we are always looking out for the best interest of all stakeholders. We understand that the team is self-managing, self-organizing, self-(fill-in-the-blank…). Apart from being aware of the values and principles that make up the agile manifesto, we are also concerned that as human beings we have an unlimited propensity toward certain truths and abilities, but our ability to engage in antipatterns is somewhat limitless. Enter the antagonizing concept Groupthink. Notice it’s not spelled in 2 separate words or no hyphen to merit their joining. At first we may think there’s nothing to be concerned about this term, but with further investigation we realize that it’s not something you’d want for your agile team.

What is Groupthink?

Groupthink is defined as the consensus or directions that a group of people take when faced with a decision. It stems from anything on the fear spectrum such as intimidation, or even just plain indifference. When stemmed from intimidation, the minority members may feel like they would need to agree with the majority so they could “fit in” or avoid being reprimanded. The proponent of such actions don’t appear to be so much about “ego building” but rather about “saving face.”

What Are the Dangers of Groupthink?

Therein lies the dangers of antipatterns what we have on a day-to-day. The old adage “the road to hell is paved with good intentions” rings in. How this happens to some extent is not necessarily with that one decision made on a particular day or particular week, but actually many decisions over many weeks, months, or even years. According to the Psychologists for Social Responsibility, Groupthink brings about the following inherent symptoms:

  1. Illusion of invulnerability –Creates excessive optimism that encourages taking extreme risks.
  2. Collective rationalization – Members discount warnings and do not reconsider their assumptions.
  3. Belief in inherent morality – Members believe in the rightness of their cause and therefore ignore the ethical or moral consequences of their decisions.
  4. Stereotyped views of out-groups – Negative views of “enemy” make effective responses to conflict seem unnecessary.
  5. Direct pressure on dissenters – Members are under pressure not to express arguments against any of the group’s views.
  6. Self-censorship – Doubts and deviations from the perceived group consensus are not expressed.
  7. Illusion of unanimity – The majority view and judgments are assumed to be unanimous.
  8. Self-appointed ‘mindguards’ – Members protect the group and the leader from information that is problematic or contradictory to the group’s cohesiveness, view, and/or decisions.

Does an Agile Mindset Prevent Groupthink?

Does removing a wrong statement from research make it right? This is the type of question we need to ask ourselves when we are on the path of continuous improvement. If we remove what is wrong in any environment, we could forget that it was identified later on. It is sort of like removing pages history from our past. We may likely repeat this behavior. Verbalizing would definitely be a start, either through a work-session, or by documenting it at some point. When something is verbalized by either an individual alone, or by a group of people, there is a process of recognition that builds concensus and buy-in. This is a very important of component of practicing with an agile mindset along with the concept of transparency. We need to be cognizant that we all know what we are agreeing to, or better yet we are not tricking ourselves to fit the ideals of our own personal agendas, principles or motives. We are looking at the bigger picture and are aware that we all collectively are deciding, committing, and taking the responsibility of those decisions. 

One of the most important elements in agile processes, commonly held in the Retrospectives, is that it helps promote the feedback loop and putting all cards on the table about the direction the team is taking. That is not to say that feedback does not occur in a daily standup, sprint demo, or sprint planning as well. The empirical processes of transparency should prevent Groupthink only to the extent that the team is willing to admit they are heading in the right direction, i.e. the team members could still all willingly pave the road to detriment if they so choose. But only difference would be that at least everyone knows they all agreed to it. When we have Groupthink, there is some obscurity about the true direction the team may be taking, in most cases transparency is intentionally hidden so that the issues and concerns will not likely come to light.

For More Articles, Be Sure to Visit our Homepage

[Image courtesy of photostock at FreeDigitalPhotos.net]

August 2016 – Book of the Month

Aspiring digital businesses need overall IT agility, not just development team agility. In Agile IT Organization Design , IT management consultant and ThoughtWorks veteran Sriram Narayan shows how to infuse agility throughout your organization. Drawing on more than fifteen years’ experience working with enterprise clients in IT-intensive industries, he introduces an agile approach to “Business–IT Effectiveness” that is as practical as it is valuable.

The author shows how structural, political, operational, and cultural facets of organization design influence overall IT agility—and how you can promote better collaboration across diverse functions, from sales and marketing to product development, and engineering to IT operations. Through real examples, he helps you evaluate and improve organization designs that enhance autonomy, mastery, and purpose: the key ingredients for a highly motivated workforce.

You’ll find “close range” coverage of team design, accountability, alignment, project finance, tooling, metrics, organizational norms, communication, and culture. For each, you’ll gain a deeper understanding of where your organization stands, and clear direction for making improvements. Ready to optimize the performance of your IT organization or digital business? Here are practical solutions for the long term, and for right now.

  • Govern for value over predictability
  • Organize for responsiveness, not lowest cost
  • Clarify accountability for outcomes and for decisions along the way
  • Strengthen the alignment of autonomous teams
  • Move beyond project teams to capability teams
  • Break down tool-induced silos
  • Choose financial practices that are free of harmful side effects
  • Create and retain great teams despite today’s “talent crunch”
  • Reform metrics to promote (not prevent) agility
  • Evolve culture through improvements to structure, practices, and leadership—and careful, deliberate interventions

Agile IT Organization Design: For Digital Transformation and Continuous Delivery

Author: Sriram Narayan

Agile IT Organization Design
BUYNOW_BUTTON

Automation is Key to Agile Implementation

automation-key-agile-implementationWhile most of us in our day-to-day would typically adapt to change whenever possible, it is very likely that we mindlessly have too much to manage. This is why automation is key to agile implementation. With a mindset to find ways for automation we promote a rhythm to the workflow, the process, the communication, etc…

Agile Ceremonies and built-in automation

When we look at the agile ceremonies overall there’s a flow that we can say exists, for example: (a) scrum or standup calls should take place at the same time every day, (b) sprint planning, sprint reviews, and retrospectives all take place on days that everyone has already preset, or (c) sprints should usually keep the same duration of weeks from sprint to sprint. We may ask ourselves, are these times and dates just a random practice (or requirement) of agile? The answer is no, not necessarily. There’s a reason behind all of this.

Keeping it Simple

While you may look to adapt to change throughout all the times of the workday, it is best to make the repetition as consistent as possible. This is similar in concept to what Einstein or Steve Jobs wearing consistently same clothing every day. This is just an example to make the point, but somewhat of an interesting revelation for those who are looking to simplify their day. For some we may think this “clothing” example is a little extreme, or irrelevant. Fair enough, this would be extreme in most cases. But when we are looking at our work environment, this principle makes a lot of sense for those who want to just concentrate and make decisions on what matters most. Putting in place what doesn’t matter so much, leaves time to make decisions that do matter. This in itself makes a lot of sense.

Consistent and Regular Adaptation

With reference to automation in the workplace, we’re not referring so much to setting up your schedule or planning in advance, although this is definitely a good habit, and better than not having any at all. We are referring specifically to having meetings, code reviews, or testing done in a way so that the agile team doesn’t have to constantly think about when it needs to happen. As an example, think of this question: What do you foresee being a problem if scrum meetings change times every day? It’s obvious, the team members will most likely be late as they try to figure out what time the meeting is at, or they missed it, and therefore all that time is just wasted when it could have been used more wisely and effectively. Some may even think, that “this inconvenience is minor,” but if you add that time up over a few sprints, you may be shocked to find out the cumulative amount isn’t as minor as you may have thought. Others may think, “this is just the normal workday or workweek,” and that it’s expected. However consider the advantages of setting this automated “rhythm” so that all that is less important is already out-of-the-way, and all the more important ideas and decisions can take place without distraction or resistance.

Admittedly, finding ways to improve a process and simplifying it in a way that is conducive to automation can be tedious, but once it’s in place, it does save a lot of time in the long run. More important than time, is the quality of the decisions and thought process that will come out of it. Think of it like a slow blockage that is eventually unclogging and allowing for a release of free-flowing ideas and productivity. Look to your sprint retrospectives to point out where areas of automation can be of benefit. You may already have some in place, but that should not stop an agile team from finding others. Incrementally and over time you can automate processes infinitely, but certainly it’s best to prioritize them where the benefit is worth the effort.

For More Articles, Be Sure to Visit our Homepage

[Image courtesy of Idea go at FreeDigitalPhotos.net]


July 2016 – Book of the Month

Everyone knows that most new products fail and that building great products is hard. The Lean Product Playbook provides clear, step-by-step guidance to help you create successful products.

Lean Startup has contributed valuable ideas about product development and generated lots of excitement. But despite their enthusiasm and familiarity with the high-level concepts, many teams run into challenges trying to adopt Lean because they lack specific guidance on what to do and how to do it.

If you are interested in Lean Startup principles and want to apply them to create winning products, this book is for you. This book describes the Lean Product Process: a repeatable, easy-to-follow methodology for iterating your way to product-market fit. It walks you through how to:

  • Determine your target customers
  • Identify underserved customer needs
  • Create a winning product strategy
  • Define your minimum viable product (MVP)
  • Design your MVP prototype
  • Test your MVP with customers
  • Iterate rapidly to achieve product-market fit

This book includes two detailed, end-to-end case studies to drive home the concepts. It also describes how to build your product using Agile development and how to use analytics to optimize your product and business.

Entrepreneurs, executives, product managers, designers, developers, marketers, analysts, and anyone passionate about building great products will find The Lean Product Playbook an indispensable, hands-on resource.

 

The Lean Product Playbook: How to Innovate with Minimum Viable Products and Rapid Customer Feedback

Author: Dan Olson

Lean Product Playbook
BUYNOW_BUTTON

June 2016 – Book of the Month

In Agile Product Management with Scrum, leading Scrum consultant Roman Pichler uses real-world examples to demonstrate how product owners can create successful products with Scrum. He describes a broad range of agile product management practices, including making agile product discovery work, taking advantage of emergent requirements, creating the minimal marketable product, leveraging early customer feedback, and working closely with the development team.

Benefitting from Pichler’s extensive experience, you’ll learn how Scrum product ownership differs from traditional product management and how to avoid and overcome the common challenges that Scrum product owners face.

Coverage includes

  • Understanding the product owner’s role: what product owners do, how they do it, and the surprising implications
  • Envisioning the product: creating a compelling product vision to galvanize and guide the team and stakeholders
  • Grooming the product backlog: managing the product backlog effectively even for the most complex products
  • Planning the release: bringing clarity to scheduling, budgeting, and functionality decisions
  • Collaborating in sprint meetings: understanding the product owner’s role in sprint meetings, including the dos and don’ts
  • Transitioning into product ownership: succeeding as a product owner and establishing the role in the enterprise

This book is an indispensable resource for anyone who works as a product owner, or expects to do so, as well as executives and coaches interested in establishing agile product management.

Agile Product Management with Scrum: Creating Products that Customers Love

Author: Roman Pichler

Agile Product Management with Scrum
BUYNOW_BUTTON

Why Choose Agile?

why-choose-agileIt’s becoming more and more obvious, Agile adoption is growing at an incredible rate, and it has been estimated at roughly 10% annually. Not many who have jumped into adopting Agile have asked the question “Why Choose Agile?” To answer that question we also need to look at already existing methodologies that exist, namely Waterfall. Is it to say that waterfall is bad? or inefficient? The answer is, not necessarily. Waterfall has it’s purposes, and when applied properly it provides all the benefits that are expected from a project that is using it…the key words here “applied properly.” The problem with Agile adoption is that it’s considered to be relatively new, and more often than not, applied incorrectly. So here are the key differences that can help understand and promote the transition from Waterfall to Agile.

1. Process Control

In Waterfall you have phase gates that are defined similar to milestones, and they occur at every stage of the process. For each of those stages there is a request to approve each gate before it is started, furthermore the scope is defined at the beginning and can’t be changed without major impacts. Sure, you can issue a change request, but that likely changes the entire balance of the budget, resources, and timeline. In Agile on the other hand, there is empirical process control where you are redefining the scope based on priority of the preset period of a sprint (2 – 4 weeks). In this way Agile allows the highest value, business needs, and ROI that are realigned regularly. Whereas in Waterfall, you cannot and there is little possibility to change the scope mid-course. Agile therefore allows a team or business to respond to the immediate business needs of their client, thus providing higher value consistently.

2. Triple Constraints and the Perception of Success

The main components to any project are Scope, Time (Budget), and Cost. With Waterfall the Scope is typically fixed, whereby Time and Cost are flexible. Problem though is that even with a Time and Cost change there really isn’t any easy way to determine a cutoff point, and stop teams in the middle of the project while waiting for a client to make a decision. This means that in order for a project to be successful in Waterfall, ideally all 3 constraints would typically need to stay fixed with the addition of change requests. Agile on the other hand provides a way to easily fix Time and Cost while making Scope flexible. Waterfall-minded people will right away spark the question “Will all the scope be completed though?” The answer of course is “not necessarily and that’s ok.” The reason for this is that it doesn’t matter, because in Agile you are already delivering the highest value from your Time and Cost that could ever be delivered from a Waterfall project. Hard to believe at first, but for those who have completed at lease one Agile project, they know this can be attained since the highest priority/value scope is being delivered.

3. Profitability and Customer Retention

Most Waterfall-minded companies will measure their margins from project to project with the intent that each project will need to be profitable. But what happens when a project slips through the cracks and goes into the negative? Going Agile will allow for higher customer retention, after all when you provide higher value through implementing current trends in innovation, accurate and faster delivery dates, customers are more likely to stay with you for the long run. The positive side-effect to this is higher motivation within your teams. This is an added benefit to both supplier and customer since learning curves (performance states) stay intact and will very likely improve when the same team members work together for longer periods of time.

4. Delivery Schedules

Waterfall depends on the entire project to be completed before it can be delivered. This certainly gives the impression to both the development team and the client that the project is going on without end. This of course applies to projects that last longer than a few months. But with Agile, you already built in the expectation that delivery is possible at the end of each Sprint, even though in some cases you may choose not to. The main issue that has never been resolved but almost always happens in Waterfall, is the moment there’s a change request, the client asks for more scope and although they would be willing to pay more for it, they want the delivery date to stay the same. Why not just deliver in increments the way that Agile already requires you to?

There are many more reasons why you may want to choose Agile over Waterfall, but most need to be shown rather than be told what those benefits are. The key point to consider is that Agile adoption should be concrete, and should come with a fully committed paradigm shift in management and teams that are looking to implement all the necessary mindsets and tools that are needed. The most likely and best approach to adopting Agile however, is to jump into it completely and use Agile in itself to inspect and adapt. Taking on a half waterfall and half agile approach will certainly lead to adoption failure.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]


May 2016 – Book of the Month

We live in a world that is broken. For those who believe that there must be a more agile and efficient way for people to get things done, here from Scrum pioneer Jeff Sutherland is a brilliantly discursive, thought-provoking book about the leadership and management process that is changing the way we live.

In the future, historians may look back on human progress and draw a sharp line designating “before Scrum” and “after Scrum.” Scrum is that ground-breaking. It already drives most of the world’s top technology companies. And now it’s starting to spread to every domain where leaders wrestle with complex projects.

If you’ve ever been startled by how fast the world is changing, Scrum is one of the reasons why. Productivity gains of as much as 1200% have been recorded, and there’s no more lucid – or compelling – explainer of Scrum and its bright promise than Jeff Sutherland, the man who put together the first Scrum team more than twenty years ago.

The thorny problem Jeff began tackling back then boils down to this: people are spectacularly bad at doing things with agility and efficiency. Best laid plans go up in smoke. Teams often work at cross purposes to each other. And when the pressure rises, unhappiness soars. Drawing on his experience as a West Point-educated fighter pilot, biometrics expert, early innovator of ATM technology, and V.P. of engineering or CTO at eleven different technology companies, Jeff began challenging those dysfunctional realities, looking for solutions that would have global impact.

In this book you’ll journey to Scrum’s front lines where Jeff’s system of deep accountability, team interaction, and constant iterative improvement is, among other feats, bringing the FBI into the 21st century, perfecting the design of an affordable 140 mile per hour/100 mile per gallon car, helping NPR report fast-moving action in the Middle East, changing the way pharmacists interact with patients, reducing poverty in the Third World, and even helping people plan their weddings and accomplish weekend chores.

Woven with insights from martial arts, judicial decision making, advanced aerial combat, robotics, and many other disciplines, Scrum is consistently riveting. But the most important reason to read this book is that it may just help you achieve what others consider unachievable – whether it be inventing a trailblazing technology, devising a new system of education, pioneering a way to feed the hungry, or, closer to home, a building a foundation for your family to thrive and prosper.

Scrum: The Art of Doing Twice the Work in Half the Time

Authors: Jeff Sutherland, JJ Sutherland

Scrum: The Art of Doing Twice the Work in Half the Time
BUYNOW_BUTTON

6 Main Reasons Why You Must Identify Backlog Item Dependencies

6-main-reasons-must-identify-backlog-item-dependenciesWhen creating and grooming a backlog in an agile project, it may come as no surprise that there is a constant need to manage it throughout the product’s lifetime. Common expectations from those who come from the waterfall mindset, is that you would just set up a backlog and the rest should take care of itself. But as you will eventually find out, you must identify backlog item dependencies.

The reality is that the moment you create the first backlog item, metaphorically it becomes a living organism. Many may think that the most challenging part of the backlog item, would be to fully define and estimate it. It certainly is one the earliest challenges in the backlog definition phase. However, it is important to consider, that with each additional backlog item that is created, there is an increasing need to consider inter-dependencies between all items. Not a daunting task if your list is limited to 10 or 20 items, but what about a typical project where there are over 50, 100, or more items.

Without putting the carriage before the horse, it is important to consider those backlog item dependencies initially with a backlog roadmap. Then it is also necessary to make it an absolutely regular activity to take on when backlog grooming. Below we identify the many reasons why backlog item dependencies need to be identified and linked to their co-dependent items.

1. Reduced Overall Project Risk

One of the main reasons why projects fail, is that there is no planning or overview of a roadmap before starting. Certainly, an agile project will prevent most of that with the regular sprint iterations and planning that happens before each is ready to start. However, what we are referring to here is more about consideration of what needs to be built, the moving parts, before all pieces of software or product can be put together. As an example, you can work on the roof of a house long before the house is actually built, but you eventually need to know that you need to build the foundation and structure before you will get to the roof installation. Further to that, you would need to identify the structural specifications (dependencies) to know that the roof will fit when the time comes to finalizing the house.

2. Value-added Efficiencies in Process Workflow

When your project is in mid flight, the last thing you want to get stuck with is realizing you just randomly selected some backlog items that don’t make sense to be in the current sprint. In the worst of cases, you would likely just leave it out as part of the grooming process. But on the other end, you would want to avoid idle time mid-sprint realizing that there were a lot of items that could’ve, should’ve, or shouldn’t have been there to begin with.

3. Facilitation of Priorities

As you identify dependencies early on in the project, the priority of all backlog items naturally present themselves. Like a seemless puzzle being put together from top to bottom, relating backlog items to see if there are or aren’t dependencies is tedious at first, but it becomes easier to balance as the software or product is being built.

4. Early Elimination of Blockers and Time Wasted

On a day-to-day process, through scrums and standups, a well groomed backlog allows for all team members to avoid getting stuck on blockers. Some blockers are inevitable based on the circumstances of the development process. But there can easily be blockers present on some aspect that could have easily been prevented, i.e. environment availability for a developer who would like to commit their code. Some blockers can have workarounds, but inevitably, the longer it is blocked, the more likely there will be time waste later on.

5. Proactive Conflict Resolution within Teams

When the teams gets to see the benefits of dependency identification, they will go on to assure there is regular backlog grooming almost intuitively. Each member’s best interests will gear toward pro-activity so that there is the least amount of conflict. Further to this, the team will be better prepared to resolve conflict should there be at any point. This is mainly a result of “lessened” levels of conflict. 

6. Increased Morale within Teams

As a direct result of lessened conflict, there will be heightened synergy among teams. They will have a higher tendency to gel together and get along. Effectively, this will prevent turnover and burnout with members of the team. Low turnover means that the team stays intact over long periods of time, and they benefit from not only being at the performing stage of team synergy, but also from the experience of working together for long periods of time. This benefit is irreplaceable and highly valuable.

Keeping an up-to-date backlog certainly has it’s benefits, but as we can see, keeping specifications up to date is not necessarily all about updating scope or tasks, but also continuously identifying how they are all tied together.

[Image courtesy of tigger11th at FreeDigitalPhotos.net]


 

April 2016 – Book of the Month

The basics of being a ScrumMaster are fairly straightforward: At face value all a ScrumMaster needs to do is facilitate the Scrum process and remove impediments. But being a great ScrumMaster, one who truly embodies the principles of servant-leadership and helps move a team to the high performance levels possible with Scrum, is much harder and much more elusive. In this book Geoff shares a collection of stories and practical guidance, drawn from over ten years of coaching numerous Scrum teams that will guide you on your path to greatness.

In this book you will learn:

* The skills and characteristics of great ScrumMasters
* How to generate, maintain and increase engagement from the team
* How to increase the effectiveness of the Scrum meetings, such as retrospectives and daily scrums.
* How to foster a more creative and collaborative team
* How to increase the performance of the team
* How to know when you are a successful ScrumMaster

Scrum Mastery is for practicing ScrumMasters who want to develop themselves into a great servant-leader capable of taking their teams beyond simple process compliance.

Scrum Mastery

Author: Geoff Watts

scrum-mastery
BUYNOW_BUTTON

Agile Team Behavior: Kindness Is Not a Sign of Weakness

agile-team-behavior-kindness-not-sign-of-weaknessMany in today’s corporate working environment are encouraged to show signs of confidence, strength, and leadership. The problem arises when it’s said and not shown. Some people tend to make up their own definition of leadership, or take on roles from fictitious movies. Much like leadership, there are many types: tyrannical, autocratic, cross-cultural, or servant, etc.. As we can see there’s a lot someone can interpret as proper forms of character traits. Some might say that because someone likes to tell someone else what to do, that they have a strong sense of leadership. This is false, and is not necessarily the case as history will tell.

So when it comes to drawing conclusions about someone’s leadership style, the important factors to consider are the results they provide. Do they promote failure or success? Is that very person creating a lot of adversity? Sure sometimes adversity is healthy in working environments that require change or innovation. It builds up ideas and brainstorming on how to resolve problems. But otherwise, you may be staring down an inevitable rabbit-hole of high employee turnover in the workplace. For those who try to take the easy way out, the bullies, the power-mongers, they will likely search to find easy targets to blame or throw under the bus when things don’t go their way. With today’s widely diverse and geographically distributed workforces, this could also play out to be a recipe for disaster. Stating the obvious, there’s a big difference in cultures from one country to another across the world. Even-more-so, there are huge cultural gaps with neighboring countries that share the same border.

In previous articles we’ve advocated about the agile mindset, something that can be a bit of a culture shock for those who are new to agile especially. When a working environment with constant power struggles or command-and-control tactics, receive new members that are of the agile mindset, the newcomers may be perceived as passive, non-assertive, and weak. This may be the foremost biggest challenge to bringing a company culture to becoming agile, especially when agilists are outnumbered. With these perceptions there are inevitable easy outlets by those who don’t want things to change, and lead to dismissing agile implementation altogether.

This brings us to the “kindness as a sign of weakness” perception. Socially it is everywhere, the aggressors are always seen as the strong-minded, or heroic only to be hidden from the truth, when they are in fact bullies. So what does this mean for the humble, the kind, the polite, or more importantly the “professional?” When faced with such adversity, are they actually the ones with little or no confidence? When someone is kind to their fellow bully co-workers, this is not a weakness but a sign of perseverance, and by far it is the ultimate sign of confidence. Only a confident person can put up with the bully archetype, not be intimidated, and continue doing what they enjoy doing without the disruption of their weaker counterparts.

In much of today’s society, what keeps our minds at ease is to know that there is much more of the kind and humble, than there are those who are bullies. What is important for those in agile circles, is to make a sincere choice, if the workplace is filled with those who like to harp on those who are perceiving others who are kind and humble as easy and “weak” targets, make the choice to decide moving over to another workplace or company that appreciates you. Your strength will be appreciated in like-minded circles.

[Image courtesy of Ambro at FreeDigitalPhotos.net]

Agile Culture: Stop Wasting Time On What Can’t Be Resolved

When attempting to make great accomplishments, we tend to look at issues in the workplace, or in everyday life as opportunities to be resolved. This may distract from solutions that are very obvious and perhaps more urgent or easy to resolve. You may have heard of the expression “low hanging fruit.” Typically you would hear this when tackling a new opportunity, or when there’s a clear advantage to achieving a milestone or accomplishment.

Where is Your Company Placing Importance in Their Culture?

Keeping your sights on what the top priorities are, will likely keep things lean and mean. But outside the obvious, we are also referring to what is not obvious. Circular discussions in meetings, persistent and unattainable targets that never get met, can definitely be a drain on time, resources and motivation. Some companies tend to place importance on resolving issues that can’t be resolved as the next step to a break-through. This could be fine if there’s nothing else to do, but as we may all realize, time and resources are usually restricted. In a few words, why concentrate on what you can’t do, when you can concentrate on what you can do? So much time gets wasted on the “can’t do” mentality, when it’s just a matter of approach that needs a switch or refinement. Yes, this may seem a little philosophical at the moment, but being agile does really place importance on what is being done and how to adapt new ideas and processes to what was previously done.

When a team gets stuck in anti-patterns like analysis paralysis, a stagnant state that is usually caused by concentrating on what can’t be done at the moment, is a direct result to over-analyzing beyond the knowledge, developments, or tools available today. So if your team collectively doesn’t have the knowledge or tools, the low hanging fruit may just be to concentrate on obtaining the very knowledge or tools that will get you to the next step.

Getting out of Anti-Pattern cycles

A common cause of what may create a stagnant environment is the thought that all members of a team have all the knowledge needed to resolve an issue. But again, this is more of a pretentious approach whereby everyone avoids the realization that some learning is required. The problem is, nobody tends to want to step up and be the one to say that they don’t know. This kind of attitude is usually shunned upon and seen as weakness in many companies. But what does it really mean to be “weak?” Is it admitting that you need to do some learning and getting right to learning? Or admitting that you know it all and that you can waste everyone’s time pretending that it can be done?

Learning is Not a Weakness

Ultimately, what we can observe in the situation above, is that company culture can affect the decisions and approaches that employees will take. It’s not about always taking the safe route, but allowing for mistakes to be made, and also not to perceive those who admit to needing more to learn as being the weak ones in the room. In fact, this is probably the reverse, those that need the most learning and admit to it, will actually be your strongest employees. These are your true pioneers, as they have the approach needed to admit failure in times when it’s necessary to take a bold new step to a break-through process, or discovery. The company culture will guide that behavior, so it is best to re-evaluate and adjust accordingly.

[Image courtesy of stockimages at FreeDigitalPhotos.net]


March 2016 – Book of the Month

Increasingly, large product-development organizations are turning to lean thinking, agile principles and practices, and large-scale Scrum to sustainably and quickly deliver value and innovation. Drawing on their long experience leading and guiding lean and agile adoptions for large, multisite, and offshore product development, internationally recognized consultant and best-selling author Craig Larman and former leader of the agile transformation at Nokia Networks Bas Vodde share the key action tools needed for success.

Coverage includes

  • Frameworks for large-scale Scrum for multi hundred-person product groups
  • Testing and building quality in
  • Product management and the end of the “contract game between business and R&D”
  • Envisioning a large release, and planning for multiteam development
  • Low-quality legacy code: why it’s created, and how to stop it
  • Continuous integration in a large multisite context
  • Agile architecting
  • Multisite or offshore development
  • Contracts and outsourced development

In a competitive environment that demands ever-faster cycle times and greater innovation, the practices inspired by lean thinking and agile principles are ever-more relevant. Practices for Scaling Lean & Agile Development will help people realize a lean enterprise—and deliver on the significant benefits of agility.

Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum

Authors: Craig Larman, Bas Vodde

Practices for scaling Lean
BUYNOW_BUTTON

Joining an Agile Team? Know Your Personality Type

joining-an-agile-team-know-your-personality-typeThere’s an interesting thing that happens when anyone joins a company, or a new project. The thought of an Agile Team Personality Type, its effects on team dynamics, and getting to a state of performance, gives another indication on how fast everyone will reach that state. Depending on the workplace culture, it is easily assumed that everyone joining or about to work on a project is going to be competent, knowledgeable and a contributing member of the team. This is sort of like a “honeymoon phase.” What we soon discover that this initial impression will eventually change, sometimes for the better, and possibly for the worse.

Why are Personality Type Considerations Important?

Human nature will indicate, most of us have a tendency to give the benefit of the doubt to a stranger at the very beginning of a relationship. After all if it was any other way, relationships would never exist. What we tend not to do, is think of our personalities with regard to others we are interacting with. Further to this, we don’t normally think of the other individual personalities with regard to their compatibilities to ourselves and to each other. The good news is that this one consideration can accelerate synergy and performance on many levels.

What Types of Personalities are There?

There are many theoretical personality types, some ranging from 4 (four temperaments) to 16 personality types (Myers-Briggs). Some debate on which are better, more accurate, or more thorough. Most individuals think that others are like themselves at the beginning of a relationship, after all, who do we know better than ourselves? They don’t think about personality types, for example, most will think “this person is more or less like me” until the relationship develops. Later on they think about the relationship as “this person is more or less like me, but (adding exceptions).” Eventually it ends up being “this person is not like me” or “this person is a lot like me.” This would be the natural progression. But it’s the long way. Thinking about personality types of others (and yourself) up front and early on in a group relationship will empower you to know what is the best or worst expectation to come out of a team member, either individually or as a whole.

Knowing Personalities: A First Step Toward Leadership

The irony in some projects is that we tend to get caught up in the risks that could prevent the project from being completed as per the budget, timeline, or scope, but it’s taboo to think of the risk of the varying personalities that are interacting in the project. Some are compatible, and others not. But what we should stop and think about is, what actually makes a project unbearable? Is it a team working together to overcome problems? Or a team complaining about who is responsible for those problems? Knowing why this is a tendency through personality types, can allow you to take a step back, be a leader, see things outside the box, and then make the necessary preventions and adjustments.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]


February 2016 – Book of the Month

It is widely recognized that moving from traditional to agile approaches to build software solutions is a critical source of competitive advantage. Mainstream agile approaches that are indeed suitable for small projects require significant tailoring for larger, complex enterprise projects. In Disciplined Agile Delivery, Scott W. Ambler and Mark Lines introduce IBM’s breakthrough Disciplined Agile Delivery (DAD) process framework, which describes how to do this tailoring. DAD applies a more disciplined approach to agile development by acknowledging and dealing with the realities and complexities of a portfolio of interdependent program initiatives.

Ambler and Lines show how to extend Scrum with supplementary agile and lean strategies from Agile Modeling (AM), Extreme Programming (XP), Kanban, Unified Process (UP), and other proven methods to provide a hybrid approach that is adaptable to your organization’s unique needs. They candidly describe what practices work best, why they work, what the trade-offs are, and when to consider alternatives, all within the context of your situation.

Disciplined Agile Delivery addresses agile practices across the entire lifecycle, from requirements, architecture, and development to delivery and governance. The authors show how these best-practice techniques fit together in an end-to-end process for successfully delivering large, complex systems–from project initiation through delivery.

Coverage includes:

  • Scaling agile for mission-critical enterprise endeavors
  • Avoiding mistakes that drive poorly run agile projects to chaos
  • Effectively initiating an agile project
  • Transitioning as an individual to agile
  • Incrementally building consumable solutions
  • Deploying agile solutions into complex production environments
  • Leveraging DevOps, architecture, and other enterprise disciplines
  • Adapting your governance strategy for agile projects

Based on facts, research, and extensive experience, this book will be an indispensable resource for every enterprise software leader and practitioner–whether they’re seeking to optimize their existing agile/Scrum process or improve the agility of an iterative process.

Disciplined Agile Delivery: A Practitioner’s Guide to Agile Software Delivery in the Enterprise
Author: Scott W. Ambler

Disciplined Agile Delivery
Buy Now

5 Micro-Aggressions That Break Synergy in Agile Teams

5-micro-aggressions-break-synergy-agile-teamsAs we’ve revealed in a previous article How To Recognize Team Synergy in Agile Teams, a team builds up its stages of forming, storming, norming and performing over time. It is in every team-member’s best interests to keep the synergy in agile teams at a “performing” level in order to carry out the tasks and deliverables set out by the project stakeholders. But as one of Niven’s laws states “It is easier to destroy than to create.” With that we’ve identified some common Micro-Aggressions that can easily destroy the team dynamic that took so much time to build up.

Micro-Aggression as described by psychologytoday.com, are the everyday verbal, nonverbal, and environmental slights, snubs, or insults, whether intentional or unintentional, which communicate hostile, derogatory, or negative messages to target persons based solely upon their marginalized group membership.

Below are some examples of common micro-aggressions that you may find the workplace, and should take action to diffuse if they become increasingly used by team members. As you may notice there are many possible situations where dialog can take the form of joking, or sarcasm in a way that the target may even smile, laugh or shrug. However, given that these statements reinforce stereotype myths they can actually be considered as micro-aggressions to some degree:

1 – Saying someone is too much of another type of ethnicity to be the one they currently are a part of

This could be in reference to one’s physical skin color, dietary or cultural preferences, or sexual preferences. Similar expressions can also present themselves when someone tells another “I didn’t know that [someone of a certain ethnicity] would like a certain food or activity [from another ethnicity].”

2 – Over-complimenting someone because it was a surprise for someone of their gender, status or ethnicity

There may be instances when someone is given a promotion, or new assignment that someone else may have wanted. Similar situations can present themselves when someone of a certain gender takes on a position that the opposite gender would typically be “expected” to have. An example of what can be said in this type of situation is “who would have thought you’d make it to the Senior Director position after just being a Manager.”

3 – Recipient of confidential information is told that someone of their status or position would not typically receive it

This situation will typically present itself when someone in a senior-level or superior position tells someone who reports to them, that they were lucky to have that “secret” information, as someone at their “level” wouldn’t typically be a privileged recipient.

4 – Being told a seemingly positive remark in a sarcastic or ambiguously negative tone

There are numerous times throughout the day where team members may tell their colleagues short and seemingly positive remarks like “Good Luck!,” “That should be fun!,” or “Yay!.” As you may notice, those expressions can be said in a truly genuine positive light, but they can also be said in a totally opposite regard.

5 – Being asked the big question “What are you?”

This question is clearly ambiguous and takes the inquiry too far to be comfortable, and it presents an entire list of potential issues that can make the target feel inferior. The “what” is probably meant to probe the target’s ethnic background, but it can certainly be taken to ask about someone’s sexual preference, gender, or in some circles their social status. The point here is that the target can be taken to be inferior to the one asking the question.

When questions of a micro-aggressive nature are asked, it’s important to realize that the person asking the question may not realize they were being an aggressor to begin with. We all have a part to play in diffusing these types of micro-aggressions, starting with ourselves. This is to say that we all may fall into the trap of asking or partaking in a micro-aggressive statement and may not have realized, intentionally or not, that we may have made someone a target in the process. Reading up or talking about the topic in the workplace may be a good first start to identifying the appropriate types of dialog to have around teams with diverse backgrounds.

[Image courtesy of Ambro at FreeDigitalPhotos.net]


5 Guidelines From Agile Modeling for Agile Best Practices

agile-modeling-guide-agile-best-practicesThroughout the life of project there are many potential pitfalls to implementing and practicing agile. As the agile principles and values are put into practice it’s important to take steps that keep the path of agile best practices for which you are looking to benefit from. The use of Agile Modeling is an excellent way to integrate agile principles and values that can complement almost any other agile methodology (i.e. Scrum, XP, etc.).

Agile Modeling components don’t all need to be implemented to make your project agile, however the more you can put in place with thought and importance in each project situation, can provide solid benefits over time. Most importantly, they provide a good framework to building an agile mindset, and integrate seamlessly in an ongoing agile project. The following is a short list of some components:

1 – Active Stakeholder Participation

As with any agile project, the best way to guarantee success is to make sure your stakeholders are involved at all times. The Product Owner usually is the voice of the stakeholders, and we would all hope that it is always that one person that could speak for many. The importance of “Active” is the key to success. There can be times where stakeholders come out from hiding and suddenly become a decisive voice (make or break) in the success of a project. Late stakeholders that become active at the end of a project open big risks as it is the most costly point at which to make changes to accommodate their expectations.

2 – Document Continuously and/or Document Late

Notice here that we mentioned “and/or,” as an approach to documenting your deliverables. It likely will depend on the type of solution and dependencies of functionalities between features as deliverables. That is to say, it’s always best to document continuously so that you don’t have to wait until the last-minute to remember which features were implemented in your solution. As expected in an agile iterative nature, you are looking to deliver a potentially shippable solution at the end of each sprint. This would require regular documentation revisions if the features were to change and evolve drastically over the course of numerous sprints.

Admittedly it sounds contradictory, but this is where it would be best to document late, since it would be less wasteful if you were to document your deliverable once all features were integrated as much as possible. Particular attention needs to be placed on the nature of the product and development. As in the case of software development, releases occur frequently, some major and some minor. Some consideration as to what will be major and minor can allow for less waste when it comes to documenting.

3 – Iteration Modeling

As the initial part of any iteration, we expect take some time for planning. Usually that time will vary from a half day to an entire day depending on the duration of your iteration/sprint. Iteration Modeling outlines the features and design of what is expected to be delivered by the end of the sprint. Some features may end up being developed in sub-parts over a number of sprints, as well as entire parts. The importance here, is to outline how modular some features may be to the rest of them. With that in place, it becomes much easier to prioritize a sprint backlog, which brings us to the next point.

4 – Prioritized Requirements

There are many factors that go into prioritizing requirements, but the one starting point to attaining this is to actually have a backlog (or list of work items) in the first place. In most cases this Sprint Backlog will come from a much larger list called the Product Backlog. As many practitioners soon find out, prioritizing is a key activity that requires identification of numerous factors such as: ROI, risks, stakeholder needs, functional dependencies, available resources, etc.

5 – Single Source Information

If there is one thing that can cause duplication is a highly bureaucratic and disorganized framework from which an organization is set up. Although seemingly simple, having one single source of information is a major challenge for an organization. Many will point to 1 wiki page as a source of information, whereas other departments try to set their own identities and create their own versions of information that gives them a sense of purpose. From an agile project approach, it is extremely important that all parties learn to use one source of information so that it is updated in 1 location to reduce redundancy and waste.

Many companies today, still strive to revise documents of the same content, but in different locations every time there’s update. Beyond just the internal operations, the complexity of multiple sources increases when working on a project where the client looks to use their own sources of project information in conjunction with that of the vendor’s information. In this scenario, duplication is not efficient and is highly wasteful throughout all organizations, as everyone struggles to find out which is the latest version of the code, documentation, template, etc.

More Agile Modeling Guidelines

From an Agile Modeling perspective there are many more components that make up the framework of agile best practices. The important factor to consider is that it will not be an overnight implementation, nor will it be an overnight success. It takes a considerable amount of time and resources to make an agile system work, but unfortunately, not many want to invest, and expect instant gratification. As history will show, even the concept of instant plug-and-play came with a series of bugs and fixes.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]


 

January 2016 – Book of the Month

Today’s new breed, eXtreme projects are different. They feature high speed, high change, high complexity, high risk, and high stress. While traditional projects follow the classic model of ready—aim—fire, eXtreme project managers succeed by shooting the gun and then redirecting the bullet while not losing sight of their moving target.

eXtreme Project Management provides a practical guide for leaders working under high risk and high pressure while producing the desired bottom-line results. Based on Doug DeCarlo’s extensive experience in working with more than 250 project teams, his eXtreme project management model is built around an integrated set of principles, values, skills, tools, and practices proven to consistently work under conditions of rapid change and uncertainty.

eXtreme project management is based on the premise that you don’t manage the unknown the same way you manage the known. It’s a people-centric approach to high performance that makes quality of life a fundamental part of the project venture.

Throughout the book, eXtreme Project Management shows project managers, sponsors, and executives how to keep projects in control and deliver business value in the face of volatility by

  • Developing a change-tolerant, quantum mind-set
  • Applying principles of self-mastery
  • Gaining and sustaining commitment to the project mission
  • Unleashing motivation and innovation
  • Establishing trust and confidence
  • Implementing a flexible project management model
  • Establishing a real-time communications infrastructure
  • Minimizing bureaucracy
  • Improving organizational agility

eXtreme project management is a dynamic and exhilarating model for any kind of project that features high doses of speed and volatility, and where failure is not an option.

eXtreme Project Management: Using Leadership, Principles, and Tools to Deliver Value in the Face of Volatility
Author: Doug DeCarlo

Extreme Project Management
BUYNOW_BUTTON

An Agile Hybrid Approach – What to Consider

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]


 

December 2015 – Book of the Month

This is the best book about Modern Scrum that you will find anywhere!

This is the Second Edition of the book, and it has been updated to include the latest, and greatest, information about Scrum.

Scrum is the world’s most popular Agile Development Framework, and it has been changing constantly since its discovery in 1995. Over the years, Scrum users have found what does (and does not) actually work, and the Scrum Framework has changed to keep up (part of Scrum’s own inspect and adapt process). The rate of change has slowed down over time and, as of late 2013, there is hope that Scrum has stabilized. This book presents that stabilized version of Scrum, along with discussions of why and how it got that way.

Dan and Doug wrote this book in order to help people with their implementations of Scrum, and to make sure they have the most current understanding of Scrum to work with. They have found that many of the ideas found in older versions of Scrum are not only out-of-date, but harmful.

Both Dan and Doug have trained and coached thousands of people, most of whom are already using Scrum. In spite of the fact that they have read about Scrum, have been trained or coached in Scrum, and are using Scrum, their most common complaint is that they need help to do it ‘right’. Dan and Doug have found that many (if not most) of them need some help.

This book is for them and others like them.

This book is not an introductory text. Dan and Doug assume that those who read this book know, or think they know, something about Scrum. This book takes a deep, exploratory, look into the Scrum framework (as it has changed over time), and offers advice about how to think about it, and how to use it. Some of this advice is philosophical, some is pragmatic, and all of it is practical.

Dan and Doug are brutally consistent and true to the essence of Scrum. This book is not the result of an academic exercise; every suggestion or conclusion in this book is grounded in real-life issues they have encountered, and suggestions that they have made for teams and people they have coached or trained.

Exploring Scrum: the Fundamentals
Authors: Dan Rawsthorne, Doug Shimp

Exploring Scrum
BUYNOW_BUTTON

 


 

How an Agile Mindset Enlightens the Subconscious Mind

how-agile-mindset-enlightens-subconscious-mindAccording to many experts on the subconscious mind, there’s a very close correlation to our actions from what we think. That is to say, generally there’s a link to what we do because of the way we think, and vice versa. The interesting part is that the subconscious is like a database that is either controlling or being controlled. It controls us on a regular basis and is based on what has happened to us in the past, and can be controlled when we consciously choose to do so. Much like the example of beliefs, if we don’t know why we believe something, but continue to express those beliefs, we are being controlled by our subconscious. Somewhere and at some time, we were led to believe something and have locked it in so that our actions continue to reflect it. Knowing this, we can look to see how the agile mindset enlightens the subconscious mind.

Understanding our Thoughts

If at some point we ask ourselves why our beliefs are there, we may actually be able to change them if we ask the right questions, and refer back to the time when the belief may have been etched into our subconscious. We can however, de-magnetize our thoughts by performing actions that were purposefully and consciously done to overcome subconscious blocks.

Ever wonder why some companies have a culture of having constant meetings, with numerous (and possibly unnecessary) attendees? They may not actually realize that they are wasting each other’s time, and possibly inviting coworkers that could have been best left uninvited so that they could use their time more productively. This leaves many in the workplace crippled from doing their tasks when needed and may need to double efforts to catch up on the more important stuff. To a great extent it comes with learning to self-respect and then in turn that exhibits respect toward others. The best way to respect oneself is to know oneself. You owe it to yourself and others around you to understand the duality of our conscious vs. subconscious influences and the power they can give or take away.

Making Conscious Decisions and Following Through

When we practice agile on a daily basis, and follow the agile values and principles, we may have to take that first step in understanding why we are actually agreeing to do things and think along the lines of what agile represents. Is it because one person had an idea to do things according to agile values, or was it a collective decision? Regardless of the answer, this is the “first step” type of question you need to start asking. Some decide on what they heard, some from their experience, and others go by what is based on faith. If you really want to get your Agile teams set in the right direction, it is important as an agile coach, or as someone championing agile within the organization to ask those questions and get feedback. The result should be from a collective consensus to agree that there is a genuine desire to adopt agile methodologies.

The law of your mind is the law of belief, so all events will follow from that as you work as an individual and as a group in an organization. So as someone practicing agile, you have to make a conscious decision and commit that you will cooperate and apply what is available, and keep it simple and lean. As we know that beyond the agile tools, events, ceremonies, is actual thought process that makes someone do things in a way that promotes the agile values and principles. Have you taken the first step in actually reading the Agile Manifesto? Have you read a comprehensive book on agile to understand some of what the great minds and gurus on the topic have to say?

How This Ties into Agile and our Subconscious

We have a lot to owe to our subconscious mind in allowing us to follow habits whether good or bad. Something as simple as why we brush our teeth, was at some point a conscious decision to properly practicing good hygiene. At this point you probably brush your teeth guided by your subconscious. Putting this into the concept of agile practices with set time-box durations (sprint planning, sprint demos, standup meetings, etc.) we are programming the subconscious as if to say, “this is something that I’m going to commit to doing regularly and repetitively. For those who have been on their umptieth sprint or agile project, they have already realized the almost seemingly thoughtless process when starting and ending their sprints. It can also be said that there’s an almost intuitive insight as to what the consequences will be if things fall outside of time-boxed events or get left out entirely. With that we can see at that point how the action-based practices have tuned the subconscious mind and helps keep in place what the agile values and principles were meant to represent.

[Image courtesy of ratch0013 at FreeDigitalPhotos.net]

November 2015 – Book of the Month

Kanban in Action is a down-to-earth, no-frills, get-to-know-the-ropes introduction to kanban. It’s based on the real-world experience and observations from two kanban coaches who have introduced this process to dozens of teams. You’ll learn the principles of why kanban works, as well as nitty-gritty details like how to use different color stickies on a kanban board to help you organize and track your work items.

About the Book

Kanban in Action is a practical introduction to kanban. Written by two kanban coaches who have taught the method to dozens of teams, the book covers techniques for planning and forecasting, establishing meaningful metrics, visualizing queues and bottlenecks, and constructing and using a kanban board.

Written for all members of the development team, including leaders, coders, and business stakeholders. No experience with kanban is required.

What’s Inside
– How to focus on work in process and finish faster
– Examples of successful implementations
– How team members can make informed decisions

 

Kanban in Action
Author(s): Marcus Hammarberg, Joakim Sunden

Kanban in Action
BUYNOW_BUTTON


 

The Values of Being Self-Made For Agile Learning

the-values-of-being-self-made-for-agile-learningYou can never lose if you are determined to learn. Having the will to learn empowers you to know what to do, even if it is eventually to find out what not to do. Agile learning experiences allow you to do just that. To put this simply, you typically have 2 paths to learn, you are either told what to do, or you find out for yourself through your own experience on what to do, i.e. trial and error. With the analogy of getting burned on the hot stove, you can be told it is hot and will burn you if you touch it, but you will never really know what that means if you’ve never been burned before. Being told relies heavily on someone else for your growth, but what happens when that other person is not there?

Why is Being “Self-Made” Important?

Give yourself the ultimate test, ask yourself if what you’ve accomplished at any stage in your life was because you were told (or expected) to do it, or you did it because you yourself were trying to determine what to do. One path removed power, the other empowered you. We tend to get distracted by true sources of power, namely money. We strive to gain monetarily, but what if someone was given that source of power, but didn’t know what to do with it? It would go to waste wouldn’t it? Placed in the hands of someone who can’t think for themselves, it could even be used to do harm. This is where the term “self-made” comes into play. There are certainly much higher value to be considered a self-made person since it solidifies and confirms that you have gained through personal choices and experiences. This also means that a self-made person gains the added toughness of dealing with failure without being able to blame others for it. This builds character and if overcome, creates innate abilities to succeed and make further attempts to make things right.

Being Part of a “Self-Made” Agile Team

The structure of the agile team is one that should rely on the concept of being “self-made.” Why? Because learning is at its peak when you have a sense of self-consciousness. You are aware, you know that what you know is not enough. We tend to look at knowledge as finite, i.e. you took the course or made the grade so now you know everything there is to know about the subject. But that couldn’t be further from the truth. This is in part what many in the workplace dislike about those who claim they know everything. A team runs much more smoothly when the stage is set that they are all in in it to learn together and if they persist unconditionally, without pointing fingers and with compassion, there is a very high likelihood that they will succeed.

Wanting to Experience: The Key to Learning

When a group of people are proud of their greatest moments, they will likely stick together for the long run. Some may see learning experiences as a stepping stone to other new ways to learn, and others see it as a one step to being complacent. However if there is one factor that is certain from successful people is that despite all the experience they have, they refuse to stop experiencing and learning. This creates efforts that other like-minded individuals can be drawn into, and the learning cycle continues. The roles of the Agile team are there for a purpose, servant leadership being a huge part of it. We all think that the Scrum Master is the only one practicing that type of leadership, but that doesn’t necessarily have to be the case. Remember that the Scrum Master is not just a role, but also a role model, so it should not be left to one person to display specific and/or positive behaviors. Admittedly, it takes good synergy and team development before you get to a point of comfort and working efficiency within teams, but it is attainable and the benefits can be realized.

In order to get started with your learning path, ask one simple question “why?”. There’s a reason why children at an early age ask that question incessantly, as humans we are wired at an early age to want to learn, but then socialized into a system where we tend to stop. Go through your list of personal “why’s” and you may notice for yourself that there is something you may not have realized is stopping you from learning.

[Image courtesy of Stuart Miles at FreeDigitalPhotos.net]


 

 

How an Agile Approach Boosts the Value Cycle

how-agile-approach-boosts-value-cycleWhen it comes to team and company performance, many old-school thinkers and business-people look to how they can cut costs. Not their fault, but to some this is the only way they can leverage their stagnant knowledge, instead of taking on an agile approach and promote increased learning. This is likely where some are labeled as “the banker” or “the accountant.” There is recent evidence that shows if we perform on both sides of the finance and marketing fence, there is a higher level of progress and efficiency overall on spending, innovation, and revenue.

Conflicting Views: Cost Cutting vs. Value Creating

There are two strategic views that play within this spectrum; either cutting costs or creating value. Cutting costs creates the concept that there is a finite source of value or income that must be compensated for. Creating value on the other hand, breaks the barrier of thinking there is a cap on source of wealth and ideas. Certainly anything to be created requires that costs be incurred, but that is not to say we must limit investment if all the signs say GO!

Cause and Effect of the Value Cycle Explained

This brings us to the traditional vs agile project standard. When you look at a traditional project, the premise is set at the beginning of the project that it will have a finite timeline and budget. In an agile project you typically don’t have these restraints because the primary concern is about product and how to build value into it. All else if done properly will generate an infinite level of return. Why? Because a product being developed in an agile environment has the implicit expectation that with time there will be more to learn about the market, product composition, and technology that will allow for improvement. Reduced cost is a byproduct of the value cycle, since there’s usually a way to produce something with higher durability making it less prone to defects and complaints. This in turn satisfies the market and creates more demand and increased prices. Volume will also increase, and as we know that also drives down the maintenance or per unit costs.

Value Cycles Are Not Meant to be Broken

The value cycle never ends, hence why typically we look at an agile project as infinite as well. Actually the term “project” can be seen as a sort of oxymoron statement when putting words “agile” and “project” together. But that is for you and your peers to debate. When we look at the constituents of the value cycle right from the beginning where we determine requirements all the way to market release, maintenance and feedback, we can see very clearly that the market isn’t picky about how a product with unique features will look like at first sight. If someone claimed that a time-machine would take up the space of a city block, many would not be concerned. They would still look to use the product and would probably line up along a few city blocks to be the first to use it. This example may be a little far-fetched, but it is used to drive the previous point into context.

Why re-iterate?

As you can see value cycles and agile are very closely tied. They are based on an iterative process. If you believe you understand a concept upon the first try, there is a very high likelihood you missed a few points. If you take the first attempt, you may be successful, or you may not. However you took the first step, and there should be no reason to stop there. There can always be better, there is never any reason to stop improving.

[Image courtesy of Idea go at FreeDigitalPhotos.net]