Announcement: New Sessions Proposed for Toronto Agile Conference 2016

Mishkin Berteig 201504 white background - 640wMishkin has proposed three sessions for the Toronto Agile Community 2016 conference.  Part of the evaluation of the sessions to determine if they will be accepted for the conference includes a voting system.  Please take a few moments of your time to check out my session proposals, and “like” them if you think they deserve it… and of course, please check out the other proposed sessions and support other potential presenters!  Here are direct links to his three sessions:

Launching an Agile Team with the Skills Matrix

JIRA is the Worst Possible Choice

Reactive and Creative Leadership in Agile Transformation


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Mike Bowler’s CSD course – Spots Still Available

SAMSUNG CAMERA PICTURES

On September 13 & 14, Mike Bowler is presenting “Writing Defect-Free Code Faster” at the Courtyard Mariot in Toronto, Ontario.

This Certified Scrum Developer (CSD) class gives developers the techniques and methods needed to directly apply Scrum processes to development.

“15 years ago, to develop something in 6 months was okay,” Mike said when I interviewed him on the phone recently. “But now, something can be in production in 20 minutes. The world has changed and we need to go with it.”

The Scrum Alliance website describes the course as aiming to support 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.”

Mike said that in an agile organization if the developers are not aware of the agile process behind Scrum they will not be developing at full capacity. This course gives them the tools they need to be able to develop faster and with less defects.

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Announcement: Participation in the PMI Symposium

Nima Honarmandan 201305 white background - head - 275 squareAt the Best Western Lamplighter’s Inn on June 24, BERTEIG had a booth set up for the annual south west chapter of the PMI Symposium. In the relaxed, resort-like setting, surrounded by palm trees and tropical plants, project managers from across Ontario came together to learn through a series of workshops and seminars about the latest developments in the world of PMI.

I chatted with Director of Business Development, Nima Honarmandan about the experience. Here are a few of the highlights he shared.

WELCOMING COLONEL CHRIS HADFIELD

Photograph official portrait of Canadian Astronaut Chris Hadfield in EMU suit. Photo Date: July 19, 2011. Location: Building 8, Room 183 - Photo Studio. Photographer: Robert Markowitz
Photograph official portrait of Canadian Astronaut Chris Hadfield in EMU suit. Photo Date: July 19, 2011. Location: Building 8, Room 183 – Photo Studio. Photographer: Robert Markowitz

Colonel Chris Hadfield, best known for writing about his travel to the moon and creating YouTube videos while in space like this presented the keynote address to a captivated audience on the topic of “Managing Complexity and Change.”

Nima said the talk was inspiring and had real motivational depth.

Nima’s experience with talking with others in the business area is that unlike previous years, everyone he spoke with had in one way, shape or form had come into contact with agile. He said this is a new trend which shows how much progress agile has made over the years.

Nima’s message to the inspired participants, those managers from across the region who were feeling ready to embrace change, was that “We can help you change!”

It was a well attended event and we look forward to it again next year.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Four Awesome Agile Links

Agile_Axioms

What is agile exactly? How do we practice it? What does it look like to be an agile product owner? What is an agile team?

One of the qualities I’ve come to admire the most about agile teams and agile ambassadors is this continuous state of learning which everyone agrees to be in.

It seems as though “being agile” gives us permission to sometimes know an answer and sometimes not to. It gives us permission to sometimes understand a situation and have a solution and sometimes not to. Agile methods have a built-in “Reality Check” which is so refreshing.

By openly communicating often in retrospectives and by making work and backlog visible the process is taken out of the abstract and into the concrete. Agile seems to put everyone on the same page ~ even if people are coming at agile from very different angles.

Recently I posted a question to the 2500+ members of the Facebook Scrum group, asking for good recommendations for meaningful resources.

Here are the TOP Four Responses:

  1. The Stacey Matrix

2. 9 Things Every Product Manager Should Know

3. How Agile Are You?

4. Think Purpose

I’m interested to read your comments about any of these four articles or sites. What do you agree with? What do you disagree with?

What has been your biggest challenge and greatest success with implementing agile methods in your work environment?


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: How Will a Product Vision Help You Succeed?

Dozens of individuals receive training to become Certified Scrum Product Owners at our public learning events in Toronto, Ontario.

What is a Product Owner? And how do they create a product vision in alignment with the team they work with? Xi Zeng, over at 3 Agile Guys blog, has some ideas worth sharing.

Here is an excerpt from his article on product vision.

How can a product vision help you?

A project always has a predefined scope and goals, therefore defining a vision for a project is in most of the cases not really necessary. A product has usually a much bigger scope and a longer life cycle, so it’s important to create a product vision in advance in order to:

  • help the business define requirements
  • be able to evaluate the value of the project
  • simplify the communication among the organisation (or with clients)
  • act as project’s compass
  • support the prioritization and decision-making in projects

The vision should consider the long term life cycle of the product and should not be easily reachable. Define even a vision that is almost impossible to reach. All short term goals should be clear defined and measurable, e.g. what is the next step in the project, next valuable goal, how to prioritize work items in backlog, etc. But the vision represents the long term future, it should stay ambitious. Just like when you’re hiking on the mountains, you can see the rocks under your feet, you know their size and form, you can touch them and even pick them up. But you can only see roughly where is the top of the mountain. While hiking, reaching the top of the mountain is our vision.

I think there is a lot of value in what Xi writes and it is worth exploring in greater depth.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: The Human Side of Agile

Scrum of Scrum photo

On the blog “Fragile” the author writes about the human side of Agile.  The author, who does not name themself anywhere on the blog, criticizes the agile movement for not giving more time to the issue around management.

Here are some of the key arguments:

  • not enough care is taken over the distinction between project and line management
  • almost all agile implementation failures could be traced back to management’s reluctance or failure to engage
  • practical guidance is needed for an agile team leader to describe how they might incorporate these ideas into their role.

The author also notes that an anecdote they wrote was included in a recent book. It basically describes a way to make the most of an environment even if management is not providing funding or space to support agile implementation.

Here is the antidote:

It may not always be possible to create the perfect working environment, however it is important to make the most of what is available. My team were looking to map their work flow using a white board and sticky notes. Unfortunately we were situated in the middle of an open plan office without access to walls, nor did we have the necessary space for a for a free standing white board. In the end we bought a roll of white board sheeting and applied it to a nearby structural pillar. Work items flowed from top to bottom and space was tight, but it served our purpose and is still in use years later.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Mishkin Berteig’s 13 Myths of Scrum

Mishkin Berteig dispels myths in some of the most challenging aspects of Scrum.

Have you been in a team where the ScrumMaster was also a Project Manager? Did you know that’s not really the role of a Scrum Master?

Or have you been participating in retrospectives which were public? Did you know they are not supposed to be?

The thirteen concepts addressed here bringing clarity and insight to Scrum Masters, Product Owners and team members.

These key principles of Scrum, when practiced regularly, improve the effectiveness of any team.

Learning a new way takes time but when the principles are clear it is easier to adopt them and implement them with focus and success.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Scrum Vs. Kanban

Vandana Roy writes a most succinct and clear description of Scrum and Kanban in this exceptional article.

Although I was first introduced to OpenAgile in 2013, Scrum and Kanban are relatively new to me this year. While not working in a tech-based department which uses these methods, I am interested in learning as much as possible about each system. I found her explanation and chart very helpful.

Here is a quote and chart she features in the article:

“Both Scrum and Kanban are unique and emphasize on more productivity with quality and efficiency for business. The table below shows advantages of both Scrum and Kanban and the commonality in both is  to keep delivering quality product.”

 

Advantages of Scrum

Advantages of Kanban

Transparency

Flexibility

Improved credibility with clients

Focus on Continuous Delivery

High Product Quality

Increased productivity and quality

Product Stability

Increased efficiency

Team members reach sustainable pace

Team members ability to focus

Allows client to change priorities and requirements quickly

Reduction of wasted work/wasted time


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Some Light Agile Humour Puts Things Into Perspective

Have you ever wanted to run an agile project?

Or maybe you are a leader in an organization who has had an agile coach approach you requesting to run an agile project?

This light & comical sketch depicts the often humorous interactions between agile coaches and corporate leaders in various departments.

At the end of this clip, the agile coach has spoken with a CEO, Human Resources, Financial Department, etc and when he goes back to the first CEO he’s had a lot of conversations about his project, but it has not yet started.

The concept of two operating models existing within the same space is so clearly illustrated here. The one framework is about upfront-planning, documentation, assessment and projection of a plan. The other framework (Agile) is about very little upfront planning with a “jump-in-and-get-started” attitude. Adjustments are made along the way with continuous reflection and learning. The product continues to improve and is ready to deliver sooner.

The most successful businesses in the world are the ones where Agile methods have been adopted in every level of an organization.

It is just changing everything.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Link: Use Scrum Planning Meetings for Agile Delivery

Dozens of new Certified Scrum Masters complete their training weekly and head back to work on Monday geared up and ready to implement what they’ve learned.

Sometimes it goes without a hitch, depending on the work environment and support from the rest of the team and management. But sometimes Scrum Masters hit road blocks and barriers and find themselves searching for creative ways to apply Scrum to create or enhance and agile environment.

This article on Storm Consulting’s website offers an excellent way to use scrum planning for agile delivery. The approach looks worth a try.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

Waterfall vs Agile

A 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.


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

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

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 PICTURES
SAMSUNG 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.

 

 

 


Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail

“Teams” Larger Than Eleven Are Not Scrum Teams

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.

Please share!
Facebooktwittergoogle_plusredditpinterestlinkedinmailFacebooktwittergoogle_plusredditpinterestlinkedinmail