Skip to content

Feed aggregator

Announcement: New Upgrades to The Scrum Team Assessment!

Learn more about transforming people, process and culture with the Real Agility Program


For those who are not familiar, The Scrum Team Assessment is your virtual Scrum coach!  Using this simple assessment, you can find out how your team is doing and ways to improve.

Recently, new upgrades have been added to the Scrum Team Assessment and it is available for use free of charge for a limited time.

The features of the Scrum Team Assessment include:

  1. Scrum Scoring – How well your team is using Scrum;
    This includes measurement of the general process, the Product Backlog, the teamwork, and effectiveness of the ScrumMaster and Product Owner.
  2. Quick Wins – High impact ways to improve right now;
    The parts of Scrum you aren’t doing well that if you improve will give you the best return on your effort investment.  Specific, practical, applicable to your team right now!
  3. Long Term Recommendations – Sustaining high-performance;
    This is the harder stuff that involves the team’s environment, culture and processes and which can make a huge difference in the long term… but requires some up-front effort.  Practical suggestions to explore the creation of a high-performance Scrum team.
  4. Financial Benefits – The bottom line for the team;
    How much money is your organization wasting on poor performance, and how much can be saved by following the recommendations in the report.  Eye-opening, and the perfect motivation for management support of improvements.
  5. Industry Comparison – How your team is doing compares to others;
    Compare your team to other teams that have participated in the Scrum Team Assessment.  This comparison gets better and better as more teams use the Scrum Team Assessment.
  6. Recommended Resources – Tailored to your team.
    Books, articles, products, training and other services that will help your team rapidly improve.

Read more about the Scrum Team Assessment and try it for your team!

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Announcement: New Upgrades to The Scrum Team Assessment! appeared first on Agile Advice.

Categories: Blogs

Links for 2016-08-05 []

Zachariah Young - Sat, 08/06/2016 - 09:00
Categories: Blogs

Agile 2016: The Lean Buffet

NetObjectives - Fri, 08/05/2016 - 15:28
The Agile Alliance's yearly US conference is a useful barometer of where many people in the Agile community are — the problems they face, the solutions they've tried, the experiences they wish to share. This year, I was paying especially careful attention to where Lean fit into the picture. The verdict: It's there, but not nearly as much as it could be. Many of the talks I attended had a nibble...

[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Categories: Companies

Agile Aus – Robot Ethics

Growing Agile - Fri, 08/05/2016 - 14:57
Robot Ethics and the Future of Human-Robot Interaction Kate Darling Kate’s talk at Agile Australia was an interesting one, and although not about agile, she raised some things about robot ethics that I had never really even considered before. Like: is it okay for a cute robot to tell your kids they should buy certain […]
Categories: Companies

How RabbitMQ Saved My SaaS

Derick Bailey - new ThoughtStream - Fri, 08/05/2016 - 13:30

Years ago I was building a distributed system that had to function with and without a network connection.

It was a standalone app for vehicle maintenance that would synchronize data with a central server.


After a lot of trial and error, I decided to use a message queue.

It handled the system’s needs perfectly. I could batch up messages while disconnected and when the connection came back, the system would send the messages.

This was the first time I used a message queue, but I was hooked instantly.

During that first project, I saw the potential power of message based patterns. From Windows to the web, my code would benefit from this new-to-me architectural style.

I built applications and frameworks – including Marionette.js on top of Backbone – with ideas that dramatically simplified complex system design.

Life was good on the front end, for the Windows apps and my JavaScript / Backbone code.

Fast forward a few years and I was building a SaaS app.

Things were going well, but as traffic grew the site was slowing down and putting strain on the database. External service calls were overwhelming the network. Code was failing and the site was crashing!

I had to do something… but, what?

I knew what I wanted to do – to take the slow code out of my Express route handlers. But I didn’t know how… at least, I thought I didn’t.

It wasn’t until I saw connectivity issues with external services that I started thinking about a message queue – the same tool that had helped me with the offline/online app, years ago.

So I did some research, not knowing what was available for free / open source message queueing.

And I found RabbitMQ.

After taking some time to educate myself and painfully work through learning RabbitMQ, I very nervously wrote and deployed my first bits of code with it.

The result was incredible.

My service went from handling a few hundred requests per minute, to tens of thousands. My SaaS was alive and healthy, again!

I could scale the back-end code separately from the web server. The system could more easily recover from catastrophic failure. And once again, I was building complex systems in small chunks that are easier to work with.

And it’s all thanks to messaging with RabbitMQ.

But… learning on your own tedious, at best.

There’s new patterns to try, new language to understand, and new code to write.

It can take months, even years, of working with a new technology on your own, to master it.

I’ve been down the path of self-learning with message queues and the associated patterns. I know how long it takes to get from where I started to where I am today.

I don’t want anyone else to travel this path alone.

For that reason, I’ve put together the fastest way to cross the chasm.

The RabbitMQ For Developers package is the resource on learning what you need to know, and why.

And if you want an inside look at the course, sign-up below. You’ll get a preview of the course that has helped hundreds of developers save their SaaS, apps and architecture.

Categories: Blogs

Targetprocess v.3.9.1: Share views with specific users, a Recent group for the Assignments list

TargetProcess - Edge of Chaos Blog - Fri, 08/05/2016 - 10:14
Share views with specific people

You can now share views and groups with specific individual users. This means that you'll no longer have to create a team in order to make views visible for specific people. Just select 'Custom sharing' in a view's Access tab and choose users who will have access to your view/group.


Added a 'Recent' group to the list of assignable users

Currently, when you open a list of users to assign somebody to an item, users are grouped by role. We've now added an additional 'Recent' group that contains users who you recently assigned to work items. Please note: This 'recent' list will only be shown if the entire list of assignable users contains more than 6 people.


Added the ability to filter cards by the date of the last state change

Do you want to filter your cards by the date of their last state change? You can now use the LastStateChangeDate field for filtering and visual encoding. For example: Let's say you want to see bugs or user stories which have been stuck in the 'In Dev' state for more than 2 weeks. Just use ?LastStateChangeDate < Today - 14(days) and EntityState.Name == 'In Dev' FilterByDate

Add specific views from the +Create menu

From now on, you can create a Board, List, Timeline, or Details view directly from the +Create menu. You don't need to create a board first and switch to another view mode afterwards. For example, if you want to create a list, just click on 'List' from the +Create menu. You can then proceed with the setup of the newly created list by clicking the Setup button on a blank template or on one of the predefined templates. All templates are filtered by whatever view mode is currently active.

  • Added an 'Assign to me' action to the List view
  • Renamed Project Team to Project Members in the `Notify by email` section of comment boxes
Fixed Bugs:
  • Fixed the Quick Add button in the Release view and Notes tab
  • Fixed the incorrect display of state and terms when a team is assigned to an inactive project in the default process
  • Fixed the 'Create bug' button's visibility in the Test Case Run view when Bug Tracking practice is off
  • Fixed an error that occured when opening Entity view after editing Allocations
  • Fixed TP2 page appearing when saving changes in the Settings->Team form
  • Fixed incorrect display of an Attachment's name if it was downloaded with extended unicode symbols
  • Fixed an error that occured when copying an entity that was attached to an Inbox message
  • Fixed display of a comment's creation time when hovering the mouse cursor over it
Categories: Companies

Six Years of Scaling Mountains

Leading Agile - Mike Cottmeyer - Thu, 08/04/2016 - 23:09


Hey everyone… thought it was worth noting that LeadingAgile had our six year anniversary this week. It’s been a hell of a run from just Dennis and I to over 60 people. I want to thank all the loyal readers of this blog… our customers… our employees… and all the awesome folks that have guided and supported us along the way. You guys have been great. Thank you!

The post Six Years of Scaling Mountains appeared first on LeadingAgile.

Categories: Blogs

Link: Mommy Dojo Kanban – First Month Review

Learn more about transforming people, process and culture with the Real Agility Program


Right from the beginning of being introduced to Agile concepts in 2013, I appreciated the word “agile” because of its easy cross-over to sports and athletics.

Last year, around the same time that I started Taekwondo classes I also started working with an agile coach on an introductory e-course for agile beginners. As I was newly developing physical and mental agility in training while simultaneously deeply reflecting on and learning new agile concepts, the metaphor of a Scrum Master being like a Black Belt really stuck a cord for me.

Recently I came across another agile-enthusiast who is also a mother, a martial arts practitioner, and a strong advocate for personal Kanban. She authored a blog called  “Scrum Family” from 2008 until 2015. I find her posts light-hearted but strong, engaging and intelligent.

Here is a link to one of my favourite of her posts where she summarizes a successful month-long “Mommy Dojo Kanban” initiative.

She wrote that, “The Mommy Dojo Kanban really works for me. It’s simple, practical and easy to maintain. The horizon is the next seven days only. When that’s done, I simply reset without sweating major analysis or statistics.”

I was encouraged by her enthusiasm, organization and perseverance and am excited to try out a few of her Kanban tips myself.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Link: Mommy Dojo Kanban – First Month Review appeared first on Agile Advice.

Categories: Blogs

Team Performance Model - by Drexler and Sibbet

Agile Complexification Inverter - Thu, 08/04/2016 - 19:28
Many of you have all heard of the Tuckman model of team dynamics (Forming, Storming, Norming, Performing).  It was created in 1966 and has become the most popular model for describing team behavior.  Is it time to level up in your mental model of team dynamics?  Are you ready for a richer more functional model?

Introducing the Team Performance Model by Drexler and Sibbet

Orientation - Why am I here?
"Orientation is about understanding the purpose of a team and assessing what it will mean to be a member.  you need to understand the reason the team exist, what will be expected of you and how you will benefit from membership.  In a new team, these are individual concerns, because the group is only potentially a team.  that is why these concerns are illustrated as occurring in your imagination at an intuitive level.  As a team leader it is important to provide time and space for people to answer these internal questions themselves."

Keys to when Orientation challenges are resolved:
 - Team Purpose
 - Team Identity
 - Membership

Blocked teams at stage 1 Orientation may show...
 - Uncertainty
 - disorientation
 - Fear

Trust Building - Who are you?
"Trust is a measure of your willingness to work together with others for something important.  Because team members have to depend on each other to be successful, trust is essential in direct relation to how much cooperation is needed to get the job done.  In the beginning of a new team's live, trust involves some risk and uncertainty about dealing with strangers.  This is why the key question is "Who are you?"  An unstated aspect of this question is wondering, "What will you expect from me?"  For a team to work well, you need to accept that you can depend on team members to work together to accomplish the team's purpose."

Keys to when trust challenges are resolved:
 - Mutual regard
 - forthrightness
 - Reliability

When a team is Blocked at stage 2, members may show...
 - Caution
 - Facade
 - Mustrust

Goal Clarification - What are we doing?
Sometimes teams have precise charters that specify what they are responsible for accomplishing.  More often, they are given a broad mandate and nee to make choices about how they will pursue that mandate and translate it into goals.  "What are we doing?"  is a more specific question than the larger question of purpose asked during Orientation.  During this stage of a new team's life, it will need to do research and develop clear understanding of the job that is required, as well as generate agreements about goals and specific deliverables."

Keys to when goal clarification challenges are resolved:
- Explicit Assumptions
- Clear integrated goals
- Shared vision

Blocked at stage 3, members may show....
- Apathy and skepticism
- Irrelevant competition

Commitment - How will we do it?
"When goals are clear and options are identified, your team is probably eager to act.  Attention moves to the question, "How will we do it?"  this stage occurs at the bottom of the "V" in the TPM, the point of the greatest constraint.  This means committing to a specific course of action, making decisions about resources, and being clear about roles.  These are also the indicators of having addressed the "turn".  Remember that the initial stages of team performance involve a good bit of trial-and-error.  Embracing these questions might require backtracking to goals, investing more in trust development, and revisiting initial purpose before you can fully resolve commitment issues."

Keys to when commitment challenges are resolved
- assigned roles
"As your team turns toward implementation everyone will want to be clear about roles and responsibilities. You may have considered these during stage three planning, but now need to commit to what your function, authority, and responsibilities will be in practice.  Role definitions have to be complete enough to cover all the tasks that must be done to accomplish your team goals while minimizing overlaps and role conflicts.  A big part of your job if you are the team leader is to help match goals to competencies, and help people step into roles that will develop their abilities and improve results for the team."

- allocated resources
"In addition to role clarity, your team must deal with another constraint - how to provide for and deploy its limited resources, including time, money, and so forth.  These hard choices usually involve setting aside some useful tasks because the resources are not available to support them.  Indecision in this area breeds confusion and stalls work.  For virtual teams, decisions about tools and communication platforms are essential at this stage.  Teams may have to negotiate with the larger organization to get the kind of tools and support they need.  This is why the TPM intersects the organization "platform" at this stage."

- decision made
"Finally, a team needs to get clear about how members will handle decision making.  Will authority be shared?  How will you stay in touch with one another?  Who can spend what funds?  In a dynamic work environment where plans can change frequently, decision about course corrections are common.  Thinking through in advance how these will be handled moves the team's focus more productively toward implementation and high performance."

Challenges at stage 4, members may show...
- dependence
- resistance

Implementation - Who does what, when, where?
"Implementation involves scheduling and sequencing work over time.  The key question is "Who does what, when, and where?"  A visible schedule, strategy, and / or process liberates the team to move into action confidently.  Conflicts and confusion arise when there is commitment but no clear way forward."

Keys to when Implementation challenges are resolved:
 - clear processes
 - alignment
 - disciplined execution

Team's blocked at stage 5, member may show...
- Conflict
- Nonalignment
- missed deadlines

High Performance - WOW!
"High performance is a WOW state, as a team masters its processes and begins to experience the ability to change goals as well as achieve them.  You can feel when it happens and observe its effects, buy not necessarily control it.  Teams achieve a flow state when trust is high and people have mastered their roles.  In a state of high performance, boundaries and individual limits soften, everything moves together, and everyone responds as if they are part of the whole.  The indicators of that having happened are spontaneous interaction, synergy, and a team that is surpassing their expectation on results.  WOW symbolizes how high performance teams transcend rational processes by working with all the human faculties - spirt, soul, mind, and body."

keys to when High Performance challenges are resolved:
- spontaneous Interaction
- synergy
- surpassing results

When a team is blocked at stage 6, members may show...
- Overload
- Disharmony

Renewal - Why continue?
"Over time the conditions that initially set your team in motion will change.  High Performances is demanding.  Don't be surprised if people ask, "Why continue?"  this key question reminds us that team performance is an ongoing process, and must be renewed by returning to Stage 1 and reassessing if the work is still needed, worthwhile, and has some personal value and meaning.  Spending time on renewal puts your team back in touch with meaning and purpose and refreshes everyone's commitment to keep going.  It also includes learning from what you have accomplished, and building a repertoire of best practices for the next journey on this or other teams.  If your team's work is completed, Renewal is the time to wrap things up, freeing members to move on to new challenges."

Keys to when renewal challenges are resolved:
- recognition and celebration
- managing change
- staying power

When team's are blocked at stage 7, members may show...
- boredom
- burnout


This is just a taste of the awesomeness of Sibbet's book on visualizations and exercises to build great teams.  Want to know more - read the book.  You will learn lots about how team move forward and backward toward performance.  And the exercises to work with teams to help them share their understand of where they are, where they are going and what might set them back are very well explained.

Reference:  Visual Teams - Graphic tools for commitment, innovation, & high performance by David Sibbet.

See Also:

Management 3.0 Workbook
7 levels of Delegation exercise

Categories: Blogs

Youth in Agile Series, Part 1: Higher Education vs. the Real World

BigVisible Solutions :: An Agile Company - Thu, 08/04/2016 - 18:00

Youth in Agile is a new blog series sponsored by SolutionsIQ that gives young Agilists a voice in a world that is constantly changing and asking increasingly more of them. The contributors to this series are college-aged individuals who are part of the SolutionsIQ community — interns, participants of a certification course, family to SolutionsIQ’s core community. As Agile becomes more and more mainstream, it’s imperative that we begin listening to the next generation of Agilists who have hopefully learned from us and our mistakes and can continue down the path of growth in the work place that this generation and previous ones have carefully laid out.

This blog was written by Conner Mattingly, a Computer Science major at Washington State University in Pullman, WA.


Higher Learning vs. the Real World


Conner Mattingly
The real world. That’s what I hear college kids say when they are referring to life outside of school. A life that involves a career and more responsibility as they move out on their own. I would hear this “real world” phrase a lot and it was always kind of funny and lighthearted, but this summer when I began an internship at SolutionsIQ the phrase gained a bit more weight for me. Since starting my internship, I have had the opportunity to experience the professional world a little every day. Now I have an increased understanding that college is, in a lot of ways, very different from the “real world”, or at least in this case, the professional world.

Learning in College

In college, the work is more spread out. Instead of dedicating 40 or so hours a week to being as productive as possible at work, in school you’re expected to do as much work as is required to get the task done. The “products” that you deliver in college are much smaller than you might have to deliver at a job as well. However, school deadlines are much closer together. If you’re a developer, these environmental differences can lead to very different styles of programming, including acquiring bad habits. In my experience, college code is slapped together without much emphasis on the overall structure of the software. An analogy is that of constructing a house and then punching holes in the walls so you can get pipes and electrical wires to where they need to go — an ugly sight. The wires get tangled, the pipes leak, and half of the pipes and wires lead into rooms where they aren’t needed. The house is a mess but somehow the sinks work and you have overhead lighting. That’s what the majority of code in college is like. Lack of experience is definitely largely to blame for this but I feel that professors in most classes don’t place emphasis where it should be. Especially since college is meant to prepare you for the “real world” — or at least that’s what I thought.

Even after a short exposure to working in a software development environment, it seems to me that my Computer Science department is definitely behind the professional world. There are only a few tracks you can take and yet in the professional world there is a vast variety of disciplines to pursue that are all beneath the umbrella of Software Development. However, I have seen the start of a shift in college in how programming classes are made available. This year I was told that in fall semester of 2016, the college that I’m attending, the Voiland College of Engineering and Architecture, is offering a Software Engineering degree in addition to the Computer Science degree. This is huge. Computer Science at my school seems to emphasize — well, the science of computers so much that I feel like we’re only learning about the lowest level languages. I’m am not angry about any of the knowledge that I have gained because it is knowledge after all. But I am very excited about the Software Engineering program; it’s a step in the right direction to help students prepare themselves for a career in software development. I just hope they keep moving in the right direction.

Interning the “Real World”

I think the main disconnect between my school experience and my interning experience is the topics and skills that are emphasized. In actual software development, as I said, you have to think about the structure of the code. Since code bases are so large, if you don’t structure your code well, you could end up writing such tangled code that you never get the project done. This can cost companies millions of dollars, which means you could even lose your job. In college it just results in a bad grade. That’s probably part of the reason not much emphasis is put on code structure. But even if it’s not costing a customer money, focusing on the overall structure of the code will make any developer’s life easier and result in a better product. Since code quality and organization is hugely important in professional development, there are processes that exist to aid developers in their coding endeavors. One of these methods is Agile, which I have learned a lot about while at SolutionsIQ.

Agile is a way to develop software that lets teams create products fast and efficiently. Paired with Lean and Extreme Programming practices, the path of product development becomes clearer with every step taken toward the end goal. Software development, by nature, is very flexible and adaptive. Therefore the flexible nature of Agile principles lead to a perfect coupling of process and execution. Seeing Agile and other practices used in unison this summer blew me away. When the programmers stayed true to their principles, like collaboration and rapid feedback, development was simple and clean. I learned about test-driven development (TDD), refactoring, pair programming and so much more. It was amazing to watch. Yet this beautiful way of developing a product was covered for less than an hour one day in one of my classes this last year. That doesn’t make sense since it seems like Agile development and management leads to better production. I only have one more year of classes left and I am uncertain if I’ll hear any more of Agile while attending them, but I hope I do.

Agile is a way to develop software that lets teams create products fast and efficiently.
Click To Tweet

The greatest thing about my internship has been my hands-on experience pairing with James Rosko. James is a very experienced and methodical software engineer who seems to write code with the same ease that others might draw a simple flowchart. Seeing him at work was an experience all in itself. While we were pairing, we developed the foundation for the MVC app we were planning to create. We set up the server, the database and a template for the client. What made the biggest impact on me during this process, which is quite common in development, was how James would work through any given problem. I don’t think I’ve seen anyone who could slow down and break problems down into their individual components as effectively as he did. His ability to make a problem smaller is a skill I hope to possess one day. The importance of this kind of skill is, in my opinion, one of the most important to have as a developer. Yet in school these skills are not always focused on, perhaps because of the environment. This is disappointing to me because I think that skills like these are far more important than some of the things that I have learned in school, even outside of software development. Not only do they allow for more effective problem solving, but these skills allow for an increase in learning efficiency. There are so many valuable skills that are required for, or are at least useful for, the “real world” that college, in my experience, doesn’t develop. Therefore, I think it would be beneficial for young people just starting their development careers to have access to some sort of long-term internship program where they could get the experience needed to develop professional-grade software.

In conclusion, I’m happy with the opportunity I’ve had to learn so much about software development and working in teams from professionals like James and others at SolutionsIQ. It has really changed my perspective on the “real world”. I enjoy my school work as well, but I hope that in the future there will be more programs dedicated to helping beginners like me cultivate the skills and acquire the knowledge needed to succeed in the world today.


For another young perspective of Agile, read the second blog in this series.

The post Youth in Agile Series, Part 1: Higher Education vs. the Real World appeared first on SolutionsIQ.

Categories: Companies

Develop Agility for business reasons (success factor 1 of 6)

Bruno Collet - Agility and Governance - Thu, 08/04/2016 - 15:56

If your company is making shoes, then the Agile transformation should improve selling or making shoes. As Peter Drucker once said, "companies don't make money, they make shoes." At all times you must be able to provide an articulate answer the question "how does Agility improve our business?".

"If your company is making shoes, then the Agile transformation should improve selling or making shoes."
Too often the Agile transformation is initiated for fuzzy reasons not really connected with business imperatives. Sometimes we want to "do Agile" just because the company next-door is doing it. On other occasions the need for Agility only addresses a local issue such as "we must deliver this project faster" and fails to connect to concrete business reasons. Obviously, if it is disconnected from business reasons then it has little chance to impact the business in a lasting way, which should be the goal of any transformation.

Consider this good example of the need for Agility inspired by one of my clients: "Our growth is declining by 5% per year because our banking products and channels are not attractive to growing customer segments such as millennials. We have shifted at strategic level but execution does not follow fast enough. We still have tedious annual budgeting, big projects for which we want to understand everything upfront, and rigid governance consisting in several committees involved in micro decisions. Our ability to deliver value fast and pivot is very limited."

You can see that the person has given serious thought about why Agility matters for the organization and how it could address real business challenges. We should strive to reach this kind of statement from day one in order to set the transformation wheel in motion.

How do we achieve this concretely?
Have the Agile transformation expert interview key stakeholders to understand why agility matters for them, what is their perception of Agility, and what is their sense of urgency. The interview process will also help establish trust between the Agile transformation expert and key stakeholders.

Design a simple visual connecting agile capabilities with business challenges. This visual also helps define what Agility means for the organization. Indeed although Agile puts forward a common set of principles, context is king and Agility should always be defined within a context. In particular, by explicitly linking Agility with business challenges, we avoid the typical pitfall that stakeholders believe Agility is limited to IT teams doing Scrum. Below is an example for a Telecom organization, based on Agility Board's four A's framework. (full disclosure: Bruno Collet is Agility Board partner)

Then have the Agile transformation expert run a workshop to present findings - which are but hypotheses at this point - and elicit a shared vision, sense of purpose and urgency with key stakeholders.

Grounding the Agile transformation in compelling business reasons creates awareness and desire to transform, which incidentally are the two first steps of the ADKAR model (awareness, desire, knowledge, ability, reinforcement).

What could happen if we don't do this at the start?
Stakeholders will have different perceptions of the business situation (awareness), vastly diverging views on Agility (from Scrum to strategic agility and everything in-between), and varying degrees of desire to take action (from "looks interesting, we should think about it someday" to "we must do it now, we're already late"). As a consequence, the transformation will probably not hold or will be severely downsized to the point of not being transformational anymore. Remember that in a system made of interconnected people, the pace and depth of change will usually be set by the slowest, least committed among key stakeholders.

Next: Apply the Agile transformation to real challenges, immediately (success factor 2 of 6)
The 6 key success factors to start an Agile transformation the right way
Categories: Blogs

Strategies for Managing Interruptions…for Reluctant Scrum Teams

Agile Tools - Thu, 08/04/2016 - 04:29


Stop me if you have heard this before. No, really, please stop me. So there I am working to get a team launched using Scrum. They’re good folks, but frankly, they’re just doing what the boss said.

“We’re using Scrum. Tom is going to show you the ropes and get you started.”
“Right boss.”
“Training room down the hall on the right. 9:00AM sharp.”
“Got it boss.”

And so a rather wary-eyed crew shows up the next morning. As they sidle into the room we eye each other cautiously from across the conference table. I’ll admit it: I’m not feeling so hot. Combine all the glories of travel with a night in a Motel 6 and it makes a mean recipe for a mean trainer. I’m trying to guess if they are feeling as lousy as I am. Hard to tell. Maybe they always breathe through their mouths like that. I can already tell this is going to be a challenge.

So this is the part of the morning where I introduce them to ‘Satan’. No, it’s not what you think. Satan is what I call my trusty 300 page powerpoint deck that I use to break the will of my students and introduce them to the glories of Agile development. Here, have some pipe cleaners to play with while I’m talking. You can make a tiny little gun out of them and try to blow your own brains out before I finish these slides. Don’t say I don’t know how to have a good time in a meeting. Now where were we? Oh yes, here we go, slide 1…

Fifty shaky, sweaty minutes later (Dammit, where’s the coffee?), and the room full of 9 adult men is starting to look like something out of Glen Gary Glen Ross: The best thing these guys are going to get is a set of steak knives. The mood is getting ugly. We’ve just gotten to the part where I tell them that they are now part of a committed team. I can see their eyebrows shoot toward their hairlines when I say it. That’s right Judith, you only work for THIS team now. Nobody else.

The place immediately lit up like someone spitting cheap vodka on a campfire. In hindsight, I really should have seen this coming: a lot of these guys are from the operations team (for those of you new to software, operations is the software equivalent of the galley where we keep our slaves). Those guys work hard. Like breaking rocks hard. They’re interrupted so frequently, they’ll eventually get a new variety of Attention Deficit Disorder named after them. It’s merciless. If you don’t like it, no problem, we’ll find a replacement just like you.

So there I was telling them they have nothing to worry about, just tell the old boss that they’re Agile now. Yeah, tell ‘em Tom sent you. Agile teams are dedicated and can’t be pulled apart just for firefighting. Here I was, telling them that the nightmare was going to end. You’d think they’d thank me! Perhaps it was the hangover, but I just wasn’t picking up on the mood in the room with my usually alacrity. Note to self: next time stick with tequila.

So I was told, in no uncertain terms, that they fully expected to get pulled off of their work during the sprint for any number of unanticipated reasons. That was just the way things worked at this company. Managers felt perfectly entitled to pull you off a team any time they liked (after all, you were still “theirs”). This was the status quo here. It wasn’t unusual to have people who were over allocated by several hundred percent!

That’s right, it’s not just my poor alcohol addled recollection failing. These folks were expected to work simultaneously on 5 or more projects at any given time. Ouch! As I tried to tell them that was crazy, I could hear an all-too-familiar edge of hysteria creeping into their voices. Right then, it hit me like a pole axe between the eyes: I was explaining this to the wrong people! Finally sensing the disaster I was in danger of perpetuating, I did the only the only sensible thing one can do in a situation like this and beat a hasty retreat. That’s right, I needed to run away. Time for a distraction.

“Hey! I Know what to do! Let’s play a game!”
You see, when you need to distract a class and bail yourself out of a tight spot, nothing works quite as well as a game. As the team struggled to comprehend the arcane rules I’d just arbitrarily made up (I swear to God there was a beer game just like this in college) I racked my brains for ways to help these poor bastards out.

I was only confident of two things:

1) Talking to the managers would serve little or no useful purpose. Besides, I’d done that already. Just between you, me, and Machiavelli: it’s a total waste of breath. Most managers (and I speak here from experience) are normal, perfectly well meaning people, who have had the learning centers of their brains completely erased by the non-stop firefighting, infighting, and general chaos of their jobs. The average manager’s brain is like the surface of a cheap George Foreman grill: nothing sticks. But don’t despair quite yet, because there is a ray of hope…

2) Managers can be trained. I know: I used to train rats.

You see if they won’t willingly change their behavior, you can always change your own behavior. This is key to understanding change and cultures. Something has to change if you are going successfully introduce a new process (wow, that’s so utterly obvious I just got a sharp pain between the eyes). The bad news is change is hard – wicked hard. I think need a drink just contemplating change sometimes (I guess that makes me either a change agent or an alcoholic). But rather than obsessing on how to change the other guy, focus on changing yourself. Then you let them figure out how to react.

Re-energized, I finished the “Intro to Satan” for the day, kicked them out of the office, and went to do some thinking. I needed some inspiration.

Fortunately the bar wasn’t far away. Using that little epiphany as a starting point, I sat down and started writing a list of all the things that the team could do to help deal with their interrupting managers on the back of a beer coaster. It went a little bit like this (I started with the hardest one first):

  1. Say ‘No’: Yeah, I can’t say it either. It takes some practice. Repeat after me: NNNNnnn…uh,nnnuhhhhh, Nuuh, Nuuuoooo, Noo! Come on now, I know you can do it!
  2. Use Buffers: Use a time honored way of protecting schedules and buffer the heck out of yours. As soon as they figure out what you are doing, they’ll leave you alone. Well, if they are smart they will. Your mileage may vary.
  3. Use your Sheepdog: You have this wonderful creature armed with a mouthful of sharp teeth that lives to protect you from outside influence: the scrum master. Use ‘em.
  4. Cover your Buddies: If your team mate is in danger of getting nabbed, stick up for them! A chorus of “No!” is much more powerful than a piteous lone ‘no…’
  5. Escalate: Hey, use the bureaucracy for what its really good for: aggravating others.
  6. Abnormal Sprint Termination: this is a curious bit of scrum geekery that you don’t see very often, but it could work. Threaten sprint termination. Better yet, let the scrum master do it. They LOVE that kind of thing. Makes their whole day.
  7. Automate, Automate, Automate: Did I mention automate?
  8. “Tom said…” That’s right – blame it on me! It’s my fault. I admit it. I told you to say “No.” So go ahead, fire me.
  9. Working Agreement: OK, admittedly this is the most tepid offering of the bunch. But it could work, right? Put together some sort of working agreement with the managers in question. Of course that would involve communication and cooperation, and I hate the idea already. But it might work.
  10. illegible…note to self: never rest your beer on your work.

So here’s the bottom line:
Sometimes if your managers won’t change their behavior (and frankly, why should they?) then you may need to change your own behavior. You’ve got to give ‘em a reason to change. That’s what these suggestions provide – small changes in your behavior that will require changes in the organizational response.

Filed under: Uncategorized
Categories: Blogs

The 6 key success factors to start an Agile transformation the right way

Bruno Collet - Agility and Governance - Wed, 08/03/2016 - 15:52
In this series of posts we'll explore the 6 top success factors to start an Agile transformation the right way: understand why they matter, how to tackle them, and the pitfalls to avoid.

One of the main reasons Agile transformations fall short of expectations is because conditions for success are not met at the beginning. Although it's possible to adjust after starting, these success factors are so fundamental that they usually have to be present early on. Beyond knowing what has to be done, it requires courage and determination to actually do what it takes to start the Agile transformation on a solid foundation.

  1. Develop Agility for business reasons
  2. Apply the Agile transformation to real challenges, immediately
  3. Scope the Agile transformation consistently with behaviors to change
  4. Develop Agile leadership
  5. Initiate the Agile transformation as an official investment
  6. Steer the Agile transformation at executive level
Categories: Blogs

The 6 key success factors to start an Agile transformation the right way

Bruno Collet - Agility and Governance - Wed, 08/03/2016 - 15:52
In this series of posts we'll explore the 6 top success factors to start an Agile transformation the right way: understand why they matter, how to tackle them, and the pitfalls to avoid.

One of the main reasons Agile transformations fall short of expectations is because conditions for success are not met at the beginning. Although it's possible to adjust after starting, these success factors are so fundamental that they usually have to be present early on. Beyond knowing what has to be done, it requires courage and determination to actually do what it takes to start the Agile transformation on a solid foundation.

  1. Develop Agility for business reasons
  2. Apply the Agile transformation to real challenges, immediately
  3. Set organizational scope consistently with behaviors to change
  4. Change leadership behaviors
  5. Initiate the Agile transformation as an official investment
  6. Steer the Agile transformation at executive level
Categories: Blogs

Destroy The 60 Second HTTP Request

Derick Bailey - new ThoughtStream - Wed, 08/03/2016 - 13:30

How long should a “Contact Me” form take, on a website?

You type in your message, click the “send” button and …

10 seconds … 30 seconds …

… a full minute, just to send an email?!


Sure, there are a lot of steps to something as simple as sending an email.

There’s the web server handling the request, configuration for the SMTP server, opening a connection from your server to the SMTP server and handle errors for that connection.

The email needs to be formatted, and you have to send the email and wait for a response to make sure it was sent.

All of this happens every time you send an email, too. No wonder it can take thirty seconds to a minute to do something that should be simple!

But here’s the real killer… as frustrating as it is for you, a developer that knows these things, it is 100x more frustrating for the average user that expects your website to work instantly.

No one wants to stick around for 30 seconds or more.

And when you look at the largest, most popular and most used sites around, none of them make you wait around like that.

Have you ever created a new git repository on GitHub?

Perhaps you’ve paid for something with PayPal or on Amazon?

These websites and systems do not process your request in real time. They use message brokers, queues and background processing systems. They respond to you almost immediately while doing the actual work in the background.

Your web server should not be doing the heavy lifting.

Like Amazon, Github, PayPal and so many other services, your application design should use background processing for any real heavy lifting.

I’m not talking about simple select statements from a database, or even basic inserts when you’re just dealing with CRUD data, necessarily.

But any time you have real work to do where there may be a failure from a network or other external resource, you should consider a messaging system like RabbitMQ.

Any time you have work that would significantly delay the response from the web server; any time you have to handle failure with retries; any time you need to know that work has been requested and receive status updates…

It may be a network resource, such as an SMTP service. Or perhaps is an image manipulation and processing system. Webhooks are another great place where your work should be pushed into the background.

There are countless opportunities around you, where you can improve the architecture, performance and maintainability of your software system.

And these are all cases where RabbitMQ and the patterns that it brings to the table, will greatly improve your application architecture and design.

It may seem overwhelming when you first look at messaging servers, though. And that’s understandable.

But you may not realize this:

You’re already working with messaging patterns and message queues. Every day.

If you have ever sent an XHR / AJAX request from a browser, that’s an asynchronous messaging pattern.

Open your email client of choice – there’s a queuing system.

Ask a coffee shop employee to make your favorite drink, and dozens of messages will be sent between the employees and other systems to fulfill your request.

Stand in line at fast food restaurant or a bank, and you’re in another a queue.

You’re already taking advantage of the way the real world works with messages, brokers and queues.

Isn’t it about time your application architecture took advantage of this, as well?

Join my mailing list, below. I’ll send you more information on RabbitMQ and how it can improve your application architecture with messaging patterns.

You’ll hear about success in spite of failed and buggy code, and find resources on how to get started and work effectively with RabbitMQ.

Categories: Blogs

Introducing a Simple Portfolio Planning Method

Agile Product Owner - Wed, 08/03/2016 - 00:37

The SAFe Portfolio Level has been evolving rapidly.  Today, it incorporates a Lean-Agile budgeting model, a Kanban system for business and enabler epics, guidance for coordinating multiple Value Streams, connection to the enterprise business strategy, and more. But outside of the portfolio Kanban system, it hasn’t provided much actual guidance on planning for the implementation of epics. We’d like to close that gap bit with an incremental step that advances the toolset for the SAFe Portfolio. Please check out the new guidance article here.

The method is based on balancing two important concerns for Portfolio work: a) consistency of work across Value Streams and b) capacity bottlenecks in the Portfolio. It utilizes a simple view that incorporates the two perspectives, as the figure below suggests.

Figure 4. A number of Epics loaded into the plan

The method enhances the visibility into the two factors and allows the Portfolio planners to reason about the potential portfolio roadmap. There is an important caution though. One must remember that SAFe planning at the Portfolio Level can only produce input to Value Streams. The tool cannot and should not be used to commit the teams to a certain course of action; in SAFe, only teams themselves can ultimately commit to a certain scope of work. They achieve that via PI Planning. The method above aims at pre-planning and forecasting of portfolio work, rather than offering concrete expectations in terms of what should be delivered and when.

Where does this tool fit into SAFe? Clearly, as part of the Portfolio Kanban system. There, Epics get decomposed into Capabilities which are, in turn, distributed across the Portfolio Value Streams. This is where the tool turns out to be very useful. We hope to integrate this content there at some point. But of course, the same model can be used for Value Stream planing as well.

Well, this post is getting to be as long as the article, so enough said. Please check out the article,  and as always, provide feedback in the comments below.

-Alex and the rest of the Framework Team.


Categories: Blogs

Yes, There Are Agile Best Practices

Learn more about transforming people, process and culture with the Real Agility Program

Scrum of Scrum photo

I recently read an article by Jason Little entitled, “Yes, There are Agile Best Practices.”

He acknowledges that the Agile community hates the term but continues to assert that, “it’s more about the implementation of the practices as opposed to the practices themselves. [For example] Having Daily Standups, Retrospectives and Demos/Sprint Reviews are non-negotiable starting points for any team new to Agile. You don’t necessarily need to co-locate, or strip everyone of their titles, or even be Agile. The easiest way to get started when you’re new is to do these 3 best practices. How and when you do them is what will need to be adjusted over time, but not doing these 3 best practices means there’s not much point in getting started with Agile in the first place.”

He has a good point. No sense in doing best practices just for the sake of saying they are done. It’s pointless.

Any Agile team would want to include these 3 practices into their routine, otherwise they are not really considered an Agile team.

His article was informative and I enjoyed the read.

Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Yes, There Are Agile Best Practices appeared first on Agile Advice.

Categories: Blogs

Board Tyranny in Iterations and Flow

Johanna Rothman - Tue, 08/02/2016 - 20:17

I was at an experience report at Agile 2016 last week, Scaling Without Frameworks-Ultimate Experience Report. One of the authors, Daniel Vacanti said this:

Flow focuses on unblocking work. Iterations (too often) focus on the person doing the work.

At the time, I did not know Daniel’s twitter handle. I now do. Sorry for not cc’ing you, Daniel.


Possible Scrum Board. Your first column might say “Ready”

Here’s the issue. Iteration-based agile, such as Scrum, limits work in progress by managing the scope of work the team commits to in an iteration. Scrum does not say, “Please pair, swarm or mob to get the best throughput.”

When the team walks the board asking the traditional three questions, it can feel as if people point fingers at them. “Why aren’t you done with your work?” Or, “You’ve been working on that forever…” Neither of those questions/comments is helpful. In Manage It! I suggested iteration-based teams change the questions to:

  • What did you complete today?
  • What are you working on now?
  • What impediments do you have?

Dan and Prateek discussed the fiinger-pointing, blame, and inability to estimate properly as problems. The teams decided to move to flow-based agile.


Possible Kanban board. You might have a first column, “Analysis”

In flow-based agile, the team creates a board of their flow and WIP (work in progress) limits. The visualization of the work and the WIP limits manage the scope of work for the team.

Often—and not all the time—the team learns to pair, swarm, or mob because of the WIP limits.

Iteration-based agile and flow-based agile both manage the team’s work in progress. Sometimes, iteration-based agile is more helpful because the iterations provide a natural cadence for demos and retrospectives.

Sometimes, flow-based agile is more helpful because the team can manage interruptions to the project-based work.

Neither is better in all cases. Both have their uses. I use personal kanban inside one-week iterations to manage my work and make sure I reflect on a regular basis. (I recommend this approach in Manage Your Job Search.)

In the experience report, Daniel and Prateek SIngh spoke about the problems they encountered with iteration-based agile. In iterations, the team focused on the person doing the work.  People took stories alone. The team had trouble estimating the work so that it would fit into one iteration. When the team moved to flow-based agile, the stories settled into a more normalized pattern. (Their report is so interesting. I suggest you read it. Page down to the attachment and read the paper.)

The tyranny was that the people in teams each took a story alone. One person was responsible for a story. That person might have several stories open. When they walked the board, it was about that one person’s progress. The team focused on the people, not on moving stories across the board.

When they moved to flow, they focused on moving stories across the board, not the person doing the stories. They moved from one person/one story to one team/a couple of stories. Huge change.

One of the people who read that tweet was concerned that it was an unfair comparison between bad iterations and good flow. What would bad flow look like?

I’ve seen bad flow look like waterfall: the team does analysis, architecture, design specs, functional specs, coding, testing in that order. No, that’s not agile. The team I’m thinking of had no WIP limits. The only good thing about their board was that they visualized the work. They did not have WIP limits. The architect laid down the law for every feature. The team felt as if they were straightjacketed. No fun in that team.

You can make agile work for you, regardless of whether you use iterations or kanban. You can also subvert agile regardless of what you use. It all depends on what you measure and what the management rewards. (Agile is a cultural change, not merely a project management framework.)

If you have fallen into the “everyone takes their own story” trap, consider a kanban board. If you have a  ton of work in progress, consider using iterations and WIP limits to see finished features more often. If you never retrospect as a team, consider using iterations to provide you a natural cadence for retrospectives.

As you think about how you use agile in your organization, know that there is no one right way for all teams. Each team needs the flexibility to design its own board and see how to manage the scope of work for a given time, and how to see the flow of finished features. I recommend you consider what iterations and flow will buy you.

Categories: Blogs

Agile Amped Rocked Agile2016 to Bring You the Greatest Hits of the Conference!

BigVisible Solutions :: An Agile Company - Tue, 08/02/2016 - 18:00

Barry, Josh and Roxi Being Silly at Agile2016A week ago today we were deep into the biggest Agile conference of the year: Agile2016 in Atlanta, GA! Now that it’s over and done, the magic keeps living on in Agile Amped podcasts featuring some of our favorite Agilists and others we were excited to meet for the first time. Bringing new and relevant stories to the industry is our goal with these podcasts, and we hope you enjoy viewing them as much as we enjoy making them for you! Just look at us having fun with our partners ICAgile!

This year’s conference was special for us because we partnered with our friends at Sococo and DZone for the first time to put a new spin on familiar Agile topics like distributed teams, collaboration and communication, technical excellence and leadership. As you watch our podcasts from this event, you may see Mandy Ross, Director of Marketing at Sococo, and John Esposito, Editor-in-Chief of DZone. Both brought a fresh voice and perspective to Agile Amped. We’re so excited to have worked with them and look forward to doing more in the future.

Without further ado, here are the greatest hits of Agile Amped from Agile2016 in Atlanta!

What’s your favorite podcast? What would you like to hear and learn more about? Let us know in the comments! And, as always, don’t forget to subscribe below!


The post Agile Amped Rocked Agile2016 to Bring You the Greatest Hits of the Conference! appeared first on SolutionsIQ.

Categories: Companies

Agile 2016 Video Podcast Interview with Mike Cottmeyer

Leading Agile - Mike Cottmeyer - Tue, 08/02/2016 - 14:27

If you missed Mike Cottmeyer’s presentation at Agile 2016 last week, you can check out the video podcast interview we did with him following his session. On the first day of the conference, Mike presented his session – An Executive’s Step-by-Step Guide to Leading Large-Scale Agile Transformation. The presentation was well attended with over 400+/- attendees in the audience. Thanks again to everyone who made it out to Mike’s talk.



Agile 2016 Slide Deck

If you’d like to check out Mike’s presentation deck from Agile 2016, you can find it here. Once the actual presentation is posted to the Agile Alliance website we’ll have an updated link here.

whitepaper-cta 2

The post Agile 2016 Video Podcast Interview with Mike Cottmeyer appeared first on LeadingAgile.

Categories: Blogs

Knowledge Sharing

SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.