Skip to content

Feed aggregator

Announcement: ScrumMaster in Toronto, ON

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

Here is a link to a full-time contract position for a Scum Master in Toronto, Ontario.

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

The post Announcement: ScrumMaster in Toronto, ON appeared first on Agile Advice.

Categories: Blogs

Justifying TDD: A Conversation with Scott Bain

NetObjectives - Tue, 08/09/2016 - 00:24
Justifying TDD: A Conversation with Scott Bain Scott Bain and Jim Trott talk about overcoming the challenges people often have to adopting Test-Driven Development in their organization. A big part of doing TDD effectively is coming to an agreement as to what it is, why we want to do it, and how to do it. We cover quesions such as: The return on the investment in TDD... for everyone Developers...

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

Agile2016 Wrap-up

Agile Tools - Mon, 08/08/2016 - 22:00

HotelImage

Well Agile2016 is in the bag.

This years conference was the largest one yet. There were nearly 2500 attendees. That’s double what it was a few years ago. Day-to-day at the conference, there definitely felt like there were a lot more bodies. Of course that could have been the location too. This was the first conference in while that wasn’t held at a Gaylord “biodome” monster hotel. Instead it was held at the Atlanta Hyatt which is considerably smaller.

Getting into talks was a real hassle this year. Often the rooms were too small and filled up more than half an hour before the talk. People were queueing up outside the door more than an hour beforehand. It was kind of nuts. Other talks were in monster halls that were barely a quarter full. There were a lot of frustrated people.

There weren’t a lot of options for getting around the hotel either. There was a bank of elevators in the lobby that was regularly overwhelmed by the thousands of people trying to get to and from their rooms. It was kind of a mess. The rooms themselves were small and quite dark. All things considered, people were not very happy with the location for this year’s event.

As quickly became apparent, there is no lack of newbies on the bootcamp track this year. The room for my talk on impediments was packed. I heard the same for other bootcamp speakers. So the number of folks who are new to Agile is still strong. That’s encouraging.

I heard all the usual grumbling about how the various “scaling” efforts were boilerplate solutions that only enable the status quo. In the meantime, one of the most popular sessions I attended focused on creating a roadmap for transformation. In my opinion, the scaling conversation is a natural evolution of the adoption of Agile as it moves into the mainstream. It’s just not trusted by established Agile practitioners who’ve only seen healthy agile in smaller contexts (true). But that doesn’t change the fact that the big guys are feeling pain and want to get there. So like it or not, I think scaling frameworks are here to stay. And I for one, welcome our new corporate overlords…

I participated in one of the memorials to Jean Tabaka. It was very moving and it was apparent how many lives she had touched both directly and indirectly. I was there largely to support my colleagues who had worked directly with her. I found myself reflecting on what it means to be the kind of person who can share themselves that authentically with others. It’s not something that comes naturally to me. I found it instructive to ask myself how to be more genuine and authentic with people as I moved through the conference. I found myself doing battle with my natural tendency toward introversion – it takes a lot energy for me to put myself forward, to take an interest in others and try to engage.

The Impediments talk was a complete riot! I had a blast. The crowd was fun and the material, much to my surprise, continues to evolve in interesting ways that I never would have anticipated. More on that to come.

The self-experimentation talk was very challenging. Overall, it went pretty well, but I was challenged with doing a very interactive workshop in a gigantic space, I was also challenged with some of the ideas from folks who participated (thank you!), and I was challenged to consider if there are better ways to talk about experimentation. This was arguably the session where I learned the most as the presenter.


Filed under: Uncategorized
Categories: Blogs

Mapping Biases to Testing: Confirmation Bias

Xebia Blog - Mon, 08/08/2016 - 21:24
I use terminology from earlier blog posts about biases. If you have missed those posts, read part 1 here. I explain the terminology there. In the second post I wrote about the Anchoring Effect. Let me state the ‘bad news’ up front: you cannot fully avoid the confirmation bias. That’s actually a good thing, because
Categories: Companies

Waterfall vs Agile

Learn more about transforming people, process and culture with the Real Agility ProgramA Retrospective on the
History of Project Management Changing my Brain from Agile to Waterfall

Several months ago I enrolled myself in a project management class. I wanted to learn about the “old way” of doing things–that is, more simply what we would refer to as the “Waterfall” methodology.

However after taking this course, i’m now apprehensive to call it “Waterfall” as there are so many other outlying elements apart from what defines it as “Waterfall” (Gantt Charts). Instead i’d refer to this practice of project management as being “traditional” and respectful towards a more old-style way of conducting business; or, operating business within a reactive environment.

Reactivity – a measure of the deviation from the condition at which a nuclear reactor is critical.

You see, i’m more of an Agile/Scrum guy (in case you were unaware). I attended this class with an open-mind, glass-empty, eyes-open and ears-listening perspective. However, every class I attended, I compared the methods to Agile/Scrum and thus i’d like to share my learnings from the class.

Before I continue, I would just like to mention that I loved taking this class, I learned new skills, I met talented people, and I would happily take this class under any other conditions.

Item #1 Reporting

I learned, there’s no reports in Agile. You reading this would disagree, but compare this to Waterfall–nope. The traditional project management system is designed with reporting in mind; in fact I would say that reporting is the first item on the “to do” list.

Before building anything! We need to make a report for it. (Let’s call it RDD – Report Driven Development)

One could argue that this is incredibly important when there are millions of dollars at stake, shareholders that need to know where their money is going, and of course good record keeping in the unlikely event of lawsuits. However, in all this documentation, when does the project actually yield some development? This is why I call it reactive–because to use this methodology is to focus on avoiding pitfalls, and attempt to foresee explosions.

Personally, I think reports are silly. I once saw a young mother have to stay two hours late for work on a beautiful spring Friday because she had to finish a report. She was the only one left in the office, and I asked her “Why do you have to send the client the report? Why not just schedule a meeting during office hours, and give them a presentation or conduct discussions containing the data within the report?”

“That’s a good idea, I never thought of that” she replied.

Possibly another case where a “nice to have” feature is causing stress to a worker just because a project manager is following an outdated methodology.

Item #2 Ubiquitous Language

One thing I love about the traditional project management suite, is its dictionary of terms and definitions. A lot of really smart people developed and documented the standards that are used within PMP/PMI, such as academics, engineers and scientists. There’s now mountains of documentation supporting all of the concepts within the waterfall world, and rigorous thought-out processes for (almost) every instance that may occur in a project. Also, sidenote: I’m not saying that all of these career paths tend to rely exclusively on documentation, but there’s certainly a lot of documentation involved.

When I was a chef, if you were to cook on the east coast, you’d refer to the small crustacean “shrimp” as “shrimp”, if you were to travel to the west coast, all of a sudden the same crustacean would be referred to as a “prawn”. I’m sure you’ve been in a project where the east coast team used a term that was different from the west coast team, and if you consider communication to be the backbone of Scrum–this could lead to a failure.

Because of that, there’s not a word i’ve encountered within Waterfall that doesn’t have a standard definition. The word “baseline” is used to define the starting position, and that’s why I refer to this education as a “history” class. It’s the sort of stuff you learn before you get into large projects.

There’s a proper place and time for documentation, and in Agile it’s a discouraged practice. Because why have documentation when you should be acquiring the information from talking to human beings. Verbal conversation and timed-planned meetings can introduce subjects with greater accuracy and less time than a well-documented word file.

In dealing with million-dollar projects, and teams of hundreds of people there’s no room for ambiguity within language. And please keep in mind, documentation creates standardization, and it’s the processes required to generate the ubiquitous language that i’ve noticed is a shortcoming within Agile in comparison to Waterfall.

I’d say that the majority of the process we use in Agile project management exist foundationally within Waterfall–but we don’t even realize we use them. A tad bit of studying, and learning the baselines will enable individuals to fortify the foundation in their next project.

Item #3 Actual History

Yes, I learned about historical concepts within the project management world. Such as process theories and their corresponding theorists. It’s truly fascinating to learn about how we got to where we are today in terms of project management.

In 1962 Everett Rogers was considered an early adopter and supporter of modern change controls and change requests.

Ultimately, the sad truth is that the majority of processes we follow today in project management are just to cover ones ass. As, historically, the project manager tended to be the focus of “blame” when failures occur within a project.. and the first person to be fired.

Keep in mind that this project management approach is over a century old, and the Agile manifesto was formulated in 2001. So I like to believe Agility is devised for a new world of empowering teams and building stuff, however it’s very important to know where you came from.

Item #4 Quoting

The biggest takeaway from my history class, was learning about all the tools that currently exist within the antiquated project management methodology and their gorgeous tools for creating estimates.

Creating estimates is tricky in Agile; mostly because to adhere to the iterative development that the Agile framework represents, you don’t ever look too far into the future. The reality is though is that most businesses need a longterm plan and a lot of us in the Agile world use duct tape and a series of levers and pulleys to make Agile work with estimates. If you’re struggling with estimates, I recommend reading the Project Management Body of Knowledge Version 5 (PMBOK).

These guys have literally been doing estimates for an obscene length of time. I believe if we can hybridize their approach while adhering to the Agile workflow, we’ll have something that can truly change the world.

Having said that, as an entrepreneur I create a budget for all my projects. I accomplish all the business goals early-on in a project so that I can work to pivot them later. Pivoting is what it is to be an entrepreneur, and something that doesn’t work well with Waterfall–which is very un-business-like.

Item #??? RFP (Request for Proposals – Procurement Management)

This is the most ridiculous thing i’ve ever seen. I’m familiar with the RFP process as i’ve worked for corporations that thrived from the activity, and during my history class we studied more about what makes the RFP “tick”. Every time I think of RFP’s, I think of how Walmart operates, have you heard this story before?

Walmart tells it’s toothbrush suppliers how much it’s willing to buy the product for, and if the toothbrush manufacturer is unable to accommodate that price, Walmart will choose to get toothbrushes elsewhere. Problem is, there’s always that factory in China who will do it for a third of the price of North America, and create miserable working conditions for the workers. Yes, that’s the world that the RFP creates.

I love the aerospace industry. And what’s the difference between NASA and SpaceX? Well that’s easily the argument of Waterfall vs Agile–as NASA is still using the RFP when they should be considering iterative in-house development. The James Webb Telescope announced in 2002, to cost $842 million and to launch in 2010 was awarded to (what is now) Northrop Grumman Space Technologies. Northrop Grumman then released separate RFP’s to build components of the spacecraft. It then became a global initiative as subcontractors from all over the world were bidding on the components. You can probably bet that those subcontractors put-out RFPs as well.. But that’s my assumption.

TLDR: As of 2013 it’s estimated to cost a total of $8.8 Billion, and launch in 2018. Oops.

Conclusion

If I could summarize Waterfall in one sentence, it would probably be something like: “Waterfall is an excellent tool to make stakeholders happy, and get money from venture capital”. Where Agile is like “Agile is an excellent tool to get shit done, and keep everybody involved in the project at a consistent level of satisfaction.”

Every time I hear about a project going over budget, extending deadlines, and ultimately creating failures within business–really breaks my heart. You know that all the troubles from such a project creates unnecessary headaches, and potentially unemployment. Be a responsible project manager and don’t focus on the happiness of stakeholders.

Learning more about Waterfall was great, and I learned a lot more about Kaizen (iterative development, or, Agile within the Waterfall world). It has also taught me more about what truly makes Agile unique, and not just a buzzword used within industry.

**subtext: if anybody wants to challenge me to building a spacecraft using Agile/Scrum — bring it on.

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

The post Waterfall vs Agile appeared first on Agile Advice.

Categories: Blogs

Scope the Agile transformation consistently (success factor 3 of 6)

Bruno Collet - Agility and Governance - Mon, 08/08/2016 - 17:58
When initiating the Agile transformation, it's critical to understand which departments, divisions, teams, projects, and so on, will be part of the effort. You might say that it is true of any change. The difference is that an Agile transformation typically impacts several behaviors across many roles and organizational units. It does not abide by the traditional functional or process boundaries. It is the combination of several individual changes that makes Agility emerge at organizational level. In other words, it is holistic.

"It is the combination of several individual changes that makes Agility emerge at organizational level. In other words, it is holistic."
If you follow Agility topics and trends, you might have noticed a fragmentation of Agile into several flavors such as strategic agility, business agility, project agility, managerial agility, leadership agility, and probably a few more. Indeed as Agile transformations become more common we discover that these multiple facets of Agility must be integrated to achieve true Agility, sometimes coined organizational Agility.

The scope of an Agile transformation is often underestimated because in the past Agile usually started as a local change of practices at IT team or project level. It is a common pitfall to develop Agile locally, disconnected from the rest of the organization, and then try to expand it reactively as obstacles arise. Although the organizational scope can be adjusted during transformation, it has to be consistent from the start with the behaviors that need to be changed.

How can we achieve this concretely?
When initiating the Agile transformation:

  1. Determine the types of behaviors to change based on current situation and the Agile transformation's business objectives.
  2. Determiner the roles impacted based on behaviors identified. Who typically has to exhibit these behaviors?
  3. Determine the org. units, processes, projects… to be involved in order to cover these roles
  4. Include the managers/executives and relevant subject matter experts in the transformation participants
  5. Ensure you have sponsorship at the right level to gain sufficient influence on the part of the organization that will have to change


For example let's say that the objective is to shorten the cycle from idea to realization of initiatives in order to deliver better products faster and more frequently to customers and thus improve customer intimacy and profit. Ideas start at line of business. They are collected and evaluated by strategic planning experts, investment committee, and portfolio management people. The ones selected are executed by the project management office and project teams. The products are delivered by sales people and technical and business experts, as well as account managers. We notice that developing these Agile capabilities involves people from practically everywhere in the company, from project managers to line of business managers to executives to finance controllers to marketing and many more.

While some roles might have more impact than others on the transformation, remember that because the change needed is inherently holistic and transversal in a complex system, the resulting effectiveness will be severely affected by the effectiveness of its least effective part. In other words, in a complex system local improvements have little business impact. Picture that as a machine made of interconnected cogs.

That being said, we can't identify all roles and behaviors from the start, nor can we gain influence on all stakeholders from the start. Nonetheless, the high-level organizational scope of the Agile transformation should be drafted and issues, such as lack of influence on a part of the organization that must change, must be taken into account from the start with a plan to address the issue. If not, we have to be consistent and reduce the transformation's expectations. It's hard enough to change when the right people are on board. Change will not happen if they're not.

Conceptually, the adoption cycle of Agile behaviors follows the cycle of diffusion of innovations. However, the passage from one category to the next is not accidental; it has to be managed both with direction and emergence. When starting the Agile transformation, we have to ask ourselves who are the innovators and early adopters and focus on them, while keeping in mind who else - early majority, late majority - we'll involve next. All these people are in the transformation scope. I have found it useful to categorize stakeholders directly in the stakeholders list, in complement to traditional power/interest mapping.

As an Agile transformation leader it's important to have the courage to deal with scope issues right away and with full transparency. I have frequently been in a situation where a disconnect between behaviors to change and scope had to be escalated in order to decide if we either can access the right people or downgrade the transformation. Wishful thinking is not a strategy.

Next: Develop Agile leadership (success factor 4 of 6)
Previous: 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

Why do you want to become agile?

Ben Linders - Mon, 08/08/2016 - 13:16

Why becoming agileBecoming agile can help to achieve organizational goals. But setting agile as a goal for an organization does not work. The goal for a software organization should be to achieve results by delivering valuable products and services, not to become agile. Hence my question: do you know why do you want to become agile?
Yes, seriously, why would you do agile? There are lot’s of good reasons (and also some less good ones), but what’s your reason to become agile? What do you expect from agile?

Agile transformations seriously impact organizations (they should!). It’s a reorganization of people, work, and authorities. Employees are asked to think about the way they want to do their work, and to take responsibility. Managers have to give room to their employees. There must be a good reason to do all of this. You should know the reason why you want to become agile, and let everyone involved know.


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

It is important to know why you want to increase the agility of your organization and what you expect to achieve with agile. To know why would you want to work in an agile way, why you want your culture to become agile.

Again, agile is not an goal or state that needs to be reached. It’s important that every manager and employee knows why the organization starts an agile journey and what is expected from agile. Reasons to become agile

If I ask people in organizations that I work with why they want to become agile they often look surprised at first. Of course they want agile! Everybody is doing agile, so it must be good. Agile is supposed to make them faster, cheaper and better. So let’s do it. If it only was that easy … every organization should be truly agile by now.

Does knowing the reason matter? Yes, it does! If you know the reason why you want to become agile, chances of success increase significantly. If people know why they have to chance, if they see the purpose, they are more willing to do it.

Some of the reasons that I have heard in organizations on why they want to become agile are:

  • Deliver the right products and services
  • Be able to deliver faster
  • Increase customer satisfaction and win new customers
  • Create innovative products with motivated employees
  • Reduce the cost of development and management
  • Improve the quality of goods and services
  • Effective cooperation between development and management
  • (your reason here)

My advice to companies is to think about why they want to become agile. Pick one reason, and one only. State very clearly in one sentence what your main objective to become agile. What would make your agile transformation successful. Going for one goal is hard enough. Also, the reason you choose impacts the way that agile will be applied (it should!), so choose your reason carefully. What is your goal with agile?

Do you want to deliver products with good quality? Or be able to better meet the needs of your customers? Lower your costs? Increase the motivation of your employees? Whatever your reason is to become agile, contact me, and I’ll help you to get results :-).

Categories: Blogs

Second book is coming soon…

Agile In Action Blog - Staffan Nöteberg - Mon, 08/08/2016 - 12:01

COVER

It’s six years since Pomodoro Technique Illustrated was published. It’s translated into many languages and there’s 250 000 copies sold. Now, the sequel is almost here.

Cover image for my second book is ready. Full manuscript is written. Chinese publisher signed and translator is working hard. English publisher to be presented soon. It’s an exciting time. I hope you’ll enjoy the book and that it’ll make you more successful.


Categories: Blogs

Books by Ben Linders on Leanpub

Ben Linders - Mon, 08/08/2016 - 11:07

Books Ben Linders LeanpubAll of the books that I have published on Leanpub are now available in a bundle: Books by Ben Linders. You get a 30% discount when you buy my books with this bundle.

Currently this bundle contains three books:


advertisement:

Retrospectives Exercises Toolbox - Design your own valuable Retrospectives

With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.

My book What Drives Quality helps you to prevent software problems from happening by building an shared understanding what drives software quality. It enables you to effectively take actions, saving time and money!

My book Continuous Improvement makes you aware of the importance of continuous improvement, explores how it is engrained in agile, and provides suggestions that Scrum masters, agile coaches, well everybody, can use in their daily work to improve continuously and increase team and organizational agility.

My 2nd and 3rd book are being written incrementally. Currently they are only sold via Leanpub. When you buy the book on Leanpub you will automatically receive new chapters when they become available, free of charge.

All books that I will publish in the future on leanpub will be added to this bundle.

Categories: Blogs

Anti-Patterns impacting Customer Value


Value is in the eye of the beholder.  Smart people will say that the beholder is the customer. While in most companies there will be a similar saying to the “customer is king”, some have lost their way and have somehow forgotten the importance of customer and their feedback.  The result is organizational anti-patterns that impede successfully getting to customer value. There are a number of anti-patterns on why this occurs and below are four: 
  • Believing that you can pretend to know with certainty what the customer wants upfront.  The danger: the consequence of limiting options and being blind to customer feedback to shape product direction.  Otherwise known as the Pretend Certainty anti-pattern.
  • Focusing primarily on driving efficiencies through cost cutting and high resource utilization.  The danger: the unintended consequence of a lesser focus on the customer with little room to innovate and adapt.  Otherwise known as the No Room at the Innovation Inn anti-pattern.
  • Sub-optimizing for the comfort of having a well-established plan and set of well-defined processes.  The danger: the consequence of restricting change at the expense of adapting to customer needs.  Otherwise known as the Sub-Optimizing for Comfort anti-pattern. 
  • Engaging few to represent the whole.  The danger: the consequence of understanding customer pool, ignoring potential customers, and missing customer feedback to shape product direction. Otherwise known as the The Few and the Missing anti-pattern.

When you are a start up, you realize the importance of being customer value driven because if customers don’t buy the product, then your start-up goes under. Because of this and their small size, most start-ups will stay very close to the customer or potential customer.  When companies become larger, there is a greater chance these anti-patterns appear.  More process and more controls are often put into place and unfortunately this leads to restricting change.  A company may sub-optimize for their own processes and plans that distances them from their customers.  
The question is, do you see any of these anti-patterns within your organization that impact your ability to achieve customer value?  Avoid the poor “aim of the anti-pattern’.  Instead, engage with your customers and use their feedback to help you hit the customer value target!
For more information on the topic of Customer Value, consider reading the following articles:


Categories: Blogs

ANNOUNCEMENT: New Course Offering — Writing Defect-Free Code Faster!

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

What?

The ONLY Certified Scrum Developer (CSD) Training offered in Canada! This highly-coveted Scrum offering is certified by the ScrumAlliance and counts toward 21 PDUs or SEUs.

Why?

Writing Defect Free Code Faster! – This 3-Day course will prepare you for all that a Professional Developer will encounter in an Agile environment.

  • – Learn how to write defect free code that will be easy to manage over the long-term.
  • – Understand why test driven development is the key to successful product development.
  • – Delight your stakeholders and customers by giving them exemplary software.

Where?

Toronto, Ontario

When?

September 13 & 14, 2016

Who? Instructed by Senior Agile Coach Mike Bowler!

SAMSUNG CAMERA PICTURESSAMSUNG CAMERA PICTURES

Participants also receive two free books after attending the CSD training. The first book is Mishkin Berteig’s collection of the best articles from our blog Agile Advice. This book includes a multitude of useful and insightful articles about all things Agile. The second is a book of your choice from our list of recommended reading! These are the most important books for people using Scrum: books about technical topics, processes, the human side of Agile, and even corporate culture.

REGISTER NOW! 

***********************************************************

More about Certified Scrum Developer Training from Scrum Alliance:

Certified Scrum Developers have demonstrated, through a combination of formal training and a technical skills assessment, that they have a working understanding of Scrum principles and have learned specialized Agile engineering skills. The Certified Scrum Developer® course is aimed at software developers (programmers) who are building software in a Scrum environment. The goal is to expose students to the most important tools and techniques that need to be applied in order to build good software in the iterative and incremental fashion that Scrum requires. These ideas are central to the entire field of Agile software development.” –

and

By earning a Certified Scrum Developer® certification you:

  • Learn the foundations of Scrum and the scope of the Certified Scrum Developer’s role from the best minds in Scrum.
  • Demonstrate to employers and peers your attainment of core Scrum knowledge.
  • Expand your career opportunities by staying relevant and marketable across all industry sectors adopting Agile practices.
  • Engage with a community of recognized Scrum experts who are committed to continuous improvement.

As a CSD, you will also have access to a two-year membership with Scrum Alliance. Through this membership you can join local user groups and online social networks, gain access to deep discounts on gatherings and member-only resources.

 

 

 

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

The post ANNOUNCEMENT: New Course Offering — Writing Defect-Free Code Faster! appeared first on Agile Advice.

Categories: Blogs

“Teams” Larger Than Eleven Are Not Scrum Teams

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

Mobbing Team

Scrum suggests the size of the Development Team (the Scrum Team members who perform the work of the Sprint Backlog) be between three (3) and nine (9) people. (The Scrum Master and Product Owner are not included in that count unless they are also executing the work of the Sprint Backlog.) To maximize cohesion and minimize complexity, it is important larger groups be split into smaller units or downsized.

Considerations for re-organizing into multiple Scrum Teams:

  • People executing the work may be best suited to decide optimal team size and composition. Adjustments to team composition will be most effective if the team members are trusted (and supported) to re-organize around their own work.
  • Groups larger than eleven people often naturally subdivide into smaller, cross-functional sub-groups; therefore it may be possible to carefully observe which team members interact regularly while getting work done and simply acknowledge those informal arrangements.
  • In order to minimize dependencies between teams, Scrum Teams whose mandates are to own discreet Products or systems are preferable to groups whose mandates are to support “components” of larger systems.
  • Organizations which currently employ Project Management methods ought to consider changing budgeting & staffing practices to align around Product delivery rather than Project Management. Doing so will make value streams transparent and bring clarity to Product-centric team mandates.
Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

The post “Teams” Larger Than Eleven Are Not Scrum Teams appeared first on Agile Advice.

Categories: Blogs

What Do We Mean By Welcoming Complexity?

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

05 All of Scrum Diagram - Branded

A few weeks ago, Agile Advice featured an article called Face-To-Face Value highlighting the first of the Agile principles which is that face-to-face interaction is valued above technology-supported contact such as email, text or even Skype.

Recently, I came across another fantastic article written by Peter Green on his blog Agile For All. In the post, “What Do We Mean By Welcoming Complexity,” he reminds readers of the second Agile principle, namely,  that we “Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.”

His description of the concept of welcoming complexity is so inspiring that I was moved to sign up to the newsletter. No, I’m not a sponsor but I just wanted to share this enlightening reminder of one of the reasons Agile-thinking is so profound.

In the quick-fix, easy-is-better world we live in, it sure is refreshing to be reminded that welcoming complexity is worth it! When we welcome complexity we grow, we change, we become better people and the teams we work with advance because of it!

 

 

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

The post What Do We Mean By Welcoming Complexity? appeared first on Agile Advice.

Categories: Blogs

Apply the Agile transformation to real challenges, immediately (success factor 2 of 6)

Bruno Collet - Agility and Governance - Sat, 08/06/2016 - 16:03
The key principle here is to remember that people learn better by doing than by hearing or thinking about something. By doing they discover firsthand the superior results of the new behavior or practice.

Additionally, people involved in Agile transformation are very busy. They already spend 110% of their time on everyday work and all the rest tends to come on top. The Agile transformation, while strategic-and-super-interesting, competes with their daily whirlwind. The only way that participants give a chance to new behaviors is to make sure they are relevant to challenges they're facing, and that they are actionable almost immediately. Or else the learning will probably be lost.

"The only way that participants give a chance to new behaviors is to make sure they are relevant to challenges they're facing."
How do we quickly put people in action in the Agile transformation?
Don't spend too much time strategizing the Agile transformation. An Agile transformation is itself an Agile project: we plan what we can, and elaborate progressively as we learn from the feedback of concrete actions. In uncertain situations (see VUCA), strategy emerge from actions much more than actions come from strategy.

Design together a high-level roadmap made of a few phases and a few transversal streams for recurring topics (i.e., leadership, continuous value delivery…) and select together right away a few actions to apply to real work. Proceed then iteratively in plan-do-check-act (PDCA) cycle. This approach also keeps participants engaged since the Agile transformation program helps them in their everyday job.

In a 6-month Agile transformation program I was recently involved, I could put participants in action on real challenges after only three weeks. This short period was dedicated to better understand the context, generate awareness and desire to change, and elicit the overall transformation strategy and roadmap. All of which are minimal steps before participants can take effective actions.

This type of approach is sometimes referred to as action-learning.

It's equally important to attach the Agile transformation to a value-creating initiative that benefits from it. The selected initiative must be sufficiently strategic and cover similar organizational scope in order to have transformational potential. By piggybacking on a strategic, transversal initiative, the Agile transformation gains traction. For example, I had the opportunity to initiate an Agile transformation through a digitization program which spanned several functions and required developing Agile behaviors at all levels. Conversely, avoid doing a stand-alone Agile transformation project. I could not have gained access to people or have had real impact if I had initiated the Agile transformation in a vacuum. In short, don't do a "change project", do "the cultural transformation part of (for example) the digitization program".

Pitfalls to avoid
  • A detailed strategy up-front
  • An analysis phase or too many proofs of concepts
  • "Generic" Agile transformation - Not applying the Agile transformation to real initiatives
  • Waiting too long between talking about Agile and doing/being Agile
  • Relying on training and courses and expecting that learnings will naturally be put in practice

Next: Scope the Agile transformation consistently with behaviors to change (success factor 3 of 6)Previous: Develop Agility for business reasons (success factor 1 of 6)The 6 key success factors to start an Agile transformation the right way
Categories: Blogs

Announcement: New Upgrades to The Scrum Team Assessment!

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

MeetScrum

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!
Facebooktwittergoogle_plusredditpinterestlinkedinmail

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

Categories: Blogs

Links for 2016-08-05 [del.icio.us]

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.

why-rabbitmq

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

Knowledge Sharing


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