Skip to content

Feed aggregator

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

Five ways to makes your dreams come true using unexpected tools

Kanbanery - Wed, 08/03/2016 - 16:35

Artykuł Five ways to makes your dreams come true using unexpected tools pochodzi z serwisu Kanbanery.

Here’s a way to achieve your life goals, track your progress, set milestones, and stay motivated! As you probably know, personal development is a continuous process that is very hard to measure. To monitor if you’re staying on track and raise your motivation you can use agile tools like an online kanban board. Harness the same solutions that work for top businesses to achieve your personal goals.

An online kanban board (like Kanbanery) can be used for just about anything, from tracking your latest initiative to creating a learning schedule, recording goals, and brainstorming ideas. Get inspired by these five personal development kanban boards.

1. Learn a new language

Have you ever signed up for an online course or started learning a new language, and then just forgot about it? Learning new things requires not only self-discipline but also good organizational skills. If you skip classes once, you risk of making a habit of skipping classes. Use a kanban tool to create your action plan. For example, learn Spanish in 100 days. On your online kanban board you can plan your activities and monitor your learning process.

How to do it?

For instance, each class that you take online (via Coursera, Udemy, Treehouse, whatever) is a project, while each lecture is a task. To have a clear action plan you can use the task description field to make notes about the lecture, or attach your lecture notes as file attachments. An online kanban board helps you work toward completing a class entirely instead of dropping out in the second week. It is a simple, visual way to coordinate and start scheduling your lessons.

If someone you know has similar resolutions or interests as you, you can set up a shared board. In this way you can motivate each other and share your experience and knowledge. You can also make your board public and share the URL with friends, which will make you more motivated to keep progressing toward your goals.

learing language

2. Read more

Whether you’re heading off to a beach vacation or hoping to make the most of quieter work weeks, you want to catch up on your reading. Sometimes you have no idea what to read. How many times has someone told you about a great book but you haven’t written down the title and then you forgot it? Or maybe you read something crucial for your work but when you want to look it up again, you don’t remember where you found it? If any of these situations sounds familiar to you, it’s time to change your reading habits and consider using a project management app.

How to do it?

It is very easy. Just create a simple project board “Reading”. It allows you to keep all of your books on one list. In this way you can easily come back to every book title without cudgeling your brain.To have a clear picture of your reading progress, you can name your columns To read one day, To read soon, Reading, and Read. In this way you will see your reading flow. By using different labels you can mark book categories like hobby, travel, work, self-development, etc. You can also invite your friends to view your reading list, and even let them add their book suggestions.

An online kanban tool like Kanbanery allows you to create similar lists for movies, travels or whatever comes to your mind

Categories: Companies

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

My Personal Scrum RC1

Scrum Breakfast - Tue, 08/02/2016 - 13:21
How to do more of what you really care aboutMy Personal Scrum is a simple framework for people who want to become highly effective individuals. My Personal Scrum is based on the same values, principles and patterns as Scrum, but recognizes that organizing your life is a different challenge than developing a product in a team. The article explains My Personal Scrum and how to use it to become more effective.

In a business context, My Personal Scrum can enable managers and their staff to achieve high alignment and transparency about goals, forecasts and milestones achieved. In a personal context, spouses and partners can coach each other to set and achieve objectives together. And as a coach, you can use My Personal Scrum to enable your clients to identify and work toward their important goals in life and work.
Why My Personal Scrum?It takes just as much time to flip a quarter as to flip a penny, but the quarter is more valuable. So where should you invest your time? On the quarters, i.e on the things that bring value to you.

Sometimes resting or "chilling" is the right thing to do, and that's OK too. My Personal Scrum doesn't try to tell you what's important; it just helps you to recognize what's important to you, so you can do the right thing.

My Personal Scrum enables you ask and find answers to the key questions that enable you to make better use of your time:
  • What is important?
  • What is urgent?
  • What do I want to accomplish?
  • What am I going to do today?
Like Scrum, My Personal Scrum is defined through a small number of roles, artifacts and activities. Each of them exists to help you ask and answer these questions, and ensure that your answers are still the right answers as you and your situation evolves over time.
Unlike Scrum, My Personal Scrum has no rules to follow. My Personal Scrum consists of a few agreements to make with yourself and maybe one other person, so that you ask yourself important questions at regular intervals. If you miss a week, it's not the end of the world. If you find that certain aspects don't bring you value, it's OK not do them.I think of My Personal Scrum as kind a gravitational force - it exerts a gentle, attractive guidance that always pulls me back to doing the right thing. How does My Personal Scrum work?In a nutshell:
  • You meet with your coach or manager once per week to review the last week and plan the upcoming week.
  • You discuss what's important, what's urgent, and what you want to accomplish this week
  • You visualize your goals and tasks with a Priorities Map
  • You reserve time for important, but non-urgent goals.
  • You plan your day
I use Trello to visualize my Priorities Map and my calendar to plan my day.Read all about itWant to find out more? You can find the full description of My Personal Scrum, including how to get started, at my Saat-Network site.Call for Participation!As I write this, I have been exploring personal self-organization for four months and doing My Personal Scrum in its current form for 2 months. I know it helps me in my context, but I how do I know if it will help other people, especially if their context is significantly different from mine? In particular, the alternative of working with your manager as your Personal Product Owner needs validation.

I have started asking people to help me validate the concept for a month. Learning continues!

If you think this is cool, feel free to try it out! I would love to discuss with you what works, what doesn’t, what can be left out or what is still needed! Comments, Please!

Categories: Blogs

Targetprocess mobile for Android: Release 1.6

TargetProcess - Edge of Chaos Blog - Tue, 08/02/2016 - 09:16
List of notifications inside the application

Previously, you could get push notifications sent to your device but couldn't view a list of them inside the application. We've now put all notifications into one place, so they will be much easier to find.

You can find notifications for:

  • state changes for entities assigned to you
  • new or updated comments where you were mentioned
  • when you are assigned or unassigned to an item


Real Time View Updates

Another helpful improvement we've implemented is live updates. If someone changes an item that is displayed on your board, you will see this immediately without needing to refresh the board.

Other Improvements
  • Added description autosave so that you can recover any recently closed description drafts, even if you didn't click the "save" button
  • Added version number to the application so you can see which mobile release you're currently working with

If you have any suggestions or feedback for us, feel free to shoot us a message at

Click here to download the Android app.

Categories: Companies

Masterclasses at Agile Tour Kaunas

Ben Linders - Mon, 08/01/2016 - 18:49

agiletour2016kaunas I’m giving two masterclasses at Agile Tour Kaunas on October 11 and 12 on Retrospectives and on Agile and Lean. Tickets for these agile workshops can be bought on the Agile Tour Lithuania courses webpage.

The two masterclasses are:


Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

This is the first time that I’m giving my workshops in Lithuania. I’m grateful to Agile Lithuania for inviting me to their country.

The early bird price (till September 1st) for my masterclasses is 319 Eur (VAT not applicable). Regular price: is 379 Eur.

As an adviser, coach and trainer I helps organizations by deploying effective software development and management practices. I provide workshops and training sessions, public and private sessions. Here’s a list of my upcoming public sessions.

Categories: Blogs

Freedom from the Inside Out

J.D. Meier's Blog - Mon, 08/01/2016 - 17:13

“I am no bird; and no net ensnares me: I am a free human being with an independent will.” ― Charlotte Brontë, Jane Eyre

A while back, I did an interview on how to build persona freedom from the inside out:

J.D. Meier of Source of Insight Talks About Freedom

Freedom can mean a lot of things to different people.  For me, in this interview, it was really about the freedom to live my values, choose better responses, and empower myself so that I don’t live somebody else’s story or play the blame game or take on a victim mindset.

The interview is raw, real, and unscripted.

Somehow, I think I avoided talking like a pirate, which is pretty good for me.

I try not to have a potty mouth, but it happens.  I’m only human, and I grew up on the East coast Winking smile

Anyway, I think if you haven’t heard this interview before, you will enjoy the insights and wisdom distilled.

It’s from the school of hard knocks, and I had to learn a lot of painful lessons.

The most painful lesson of all is that there is always more to learn.

Which means that rather than think of it as a finish line you are racing to, it’s about continuously growing your skills to meet your challenges.

You are an evolving being learning how to better respond to the challenges that your circumstances and environment throw your way, while you pursuit your dreams.

Always remember that nature favors the flexible.

Freedom is about building that flexibility, and it’s a muscle that gets stronger the more you practice it.

Whether it’s by standing up to bullies, or talking back to that little voice in your head that holds you back, or choosing to live the life you want to lead, not the life others want you to lead, etc.

The wonderful thing about your personal freedom is that the more you exercise it, the more you create personal victories and reference examples to draw from, so you actually build momentum.

It’s this momentum that can help you transform and transcend any area or aspect of your life to operate at a higher level.

Or, at least you can make it a choice vs. leave it to chance.

Take back your power, live life on your terms, and create the experience you want to create…with skill.

So much of life comes down to strategies, skills, and stories.

Use leadership moments and learning opportunities to create the stories that make you come alive.

That’s your freedom in action, and that’s how you live your freedom.

Categories: Blogs

Messaging Architecture Can Be A Massive Productivity Boost

Derick Bailey - new ThoughtStream - Mon, 08/01/2016 - 13:30


A few years ago, I was doing full-time consulting.

At one particular client, we were building a component based UI where pieces of the screen could be swapped in and out pretty quickly. This was all done through clean APIs that were message based and consistent across the components.

Each component was independent of the others.

None knew about the others, directly, but would communicate through in-process messages and a centralized communication mechanism.

As I began to work on one particular screen, I noticed a problem.

We were laying out the software based on the old paper workflow, where there was information from a previous page that was needed on the current page.

In the software, however, it made more sense to move some of the current page’s components to the previous page, and some of the previous page’s components to the current one.

I thought through the reasoning and logic of the way the paper was laid out vs the changes I wanted in the software and it all made sense to me. It would significantly reduce the code size and complexity if we swapped these things around.

I called my client and we talked about the changes I wanted to make.

He agreed on the reasons for the changes I wanted – it made sense and would be better. But he was concerned about timelines.

We were already running behind, and he didn’t want to continue pushing behind further. It was a valid concern – and it was his job to make sure we met the deadlines.

I expected the change to take up to 3 days as there were a lot of parts to move around and a lot of logic to change in order to make this work.

He reluctantly agreed and asked me to see if I could get it done faster than that.

I said I would try.

15 minutes later, I told my client I was done.

The message based communication and component based architecture had given us far more freedom and flexibility in re-arranging and rebuilding the workflow than either of us had imagined.

I was able to take an estimated 3 day change and complete it in 15 minutes.

It was a great moment for both of us, to see that the work we had put into this was going to serve us well and create a system that would be far easier to maintain.

The benefits of messaging and decoupled components are many.

But, the improvements found in messaging aren’t always that dramatic.

Whether in-memory or through the use of a messaging server like RabbitMQ, these patterns can provide significant architectural advantages. That client work was a prime example of how powerful these patterns can be.

Sometimes – especially when you’re first getting started – the benefits don’t seem to be there at all.

Sometimes you’ll sit back and look at what you built, and wonder why you spent so much time on it. You find yourself looking at something that should have been “simple”, and it became complex.

The benefits are especially hard to see when first learning a technology.

Learning takes time and often creates more questions than answer.

I want to help answer those questions for you. I want to show you the benefit of messaging and good architectural practices.

I want to help you turn a 3 day estimate in to 15 minutes of work.

Join the mailing list, below, and over the next few weeks you’ll see how how these patterns can work for you.

Categories: Blogs

[UPDATE] Version R6#14.11

IceScrum - Mon, 08/01/2016 - 12:47
Hello everybody, Here comes a new version of iceScrum and iceScrum Pro! This version brings many changes, we hope that you will like them! This post lists all the changes brought by iceScrum R6#14. It is updated when minor versions are released to fix bugs and add small improvements on top of this major version.…
Categories: Open Source

Knowledge Sharing

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