Skip to content

Feed aggregator

New book! SAFe® 4.0 Reference Guide captures Framework body of knowledge in print and eBook

Agile Product Owner - Fri, 08/19/2016 - 00:37

reference_guide_400Well, we finally got here. After years of people asking for a book on SAFe, I’m happy to say that the SAFe® 4.0 Reference Guide, Scaled Agile Framework® for Lean Software and Systems Engineering is now shipping.

This guide provides the content from, but in book form for easy reference. It’s available in paperback and eBook formats (including Kindle) at major book retailers. Like the SAFe website, it provides comprehensive guidance for work at the enterprise Portfolio, Value Stream, Program, and Team levels. It also includes the various roles, activities, and artifacts that constitute the Framework, along with the foundational elements of values, mindset, principles, and practices.

Why a book, when you can get SAFe online?

We think of the Reference Guide as the ideal companion to the website. You can mark it up, scribble in the margins, read it on the plane, add sticky notes, and highlight relevant sections to make it your own. For example, the first night it was available, a student from our Denmark SPC4 class downloaded the eBook to help him study for the certification exam. He came back the next morning raving about it (I bet he passed his exam). Raves aside, we’re in the training business, and we know from experience that everyone learns and connects to information in different ways, so having SAFe captured in as many forms as possible just makes good sense.

To learn more about the SAFe Reference Guide (and to get some promotional savings!), visit

I’d like to thank my co-authors, Alex Yakyma, Richard Knaster, Drew Jemilo, and Inbar Oren, as well as the larger SAFe contributor community. Without this fusion of dedicated people, ideas, challenges, and honest feedback, SAFe wouldn’t be what it is today. It’s an exciting space in which to work as we continue to evolve the Framework, and help enterprises fulfull their mission of building better software and systems.

Stay SAFe!


Categories: Blogs

Choosing a Kanban App: 7 Things You Need to Consider

Not all Kanban apps are created equal. Read these helpful tips before choosing a Kanban app for your team.

The post Choosing a Kanban App: 7 Things You Need to Consider appeared first on Blog | LeanKit.

Categories: Companies

Announcement: BERTEIG is launching the first course of its kind in Canada!

Learn more about transforming people, process and culture with the Real Agility ProgramThe Certified Agile Leadership training is a new course. At the Orlando Scrum gathering the program was announced and shortly after, CSTs and CECs with strong leadership coaching background and formal education in this field were invited to apply to teach the class. Michael Sahota - Profile Picture (2016) Michael Sahota was one of these selected coaches. The course is an acknowledgement that Agile transformation can only go so far if it is driven from the grassroots level, or without the full support of the leadership. As a leader, they are driving a culture change in the organisation to get better results. This goes far beyond corporate mantras and motivational speeches. Participants can expext to learn the intracacies required of a leader to bring about lasting change. The target audience is C-level executives, VPs and Senior Directors with decision making capability. The training is also for Change Agents who are catalysts in an organisation, who have the drive and willingness to make a difference. Michael is known by the Scrum Alliance and since he has had taken formal non-Agile related Leadership training, his application was accepted making him the second global trainer to be approved after Pete Behrens (who is part of the creation committee of CAL) and another chap. BERTEIG is honoured to be a part of this global launch of a brand new training and we look forward to the positive feedback from many more participants! CAL1 Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Announcement: BERTEIG is launching the first course of its kind in Canada! appeared first on Agile Advice.

Categories: Blogs

Design Thinking and the Business Agility Ecosystem

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

We have entered the third wave of Agility. The first wave was about Agile teams adopting frameworks such as Scrum, Kanban and XP, the second wave was about Agile at Scale where organizations implemented scaling patterns to ensure Agile could operate at large scale. The third wave is Business Agility. To achieve a state of Business Agility, the entire organization needs to adopt an Agile mindset, effectively creating an end-to-end Agile ecosystem. And Agile today is being recognized more and more as a requirement for dealing with, as Stephen Denning put it in a recent article, “a world that is increasingly volatile, uncertain, complex and ambiguous”. Innovation is the name of the game — or at least, it’s the key to staying in the game. Lean Startup is one method for creating and sustaining innovation; another option that is getting a lot of attention these days is Design Thinking.

What is Design Thinking?

Mens et manus is the Latin phrase meaning “mind and hand”, which is the motto of Massachusetts Institute of Technology (MIT). I think this is a great way to frame a conversation about how Design Thinking is relevant to organizations trying to achieve Business Agility. Design Thinking is about testing the creative ideas that are in your mind by using your hands to give those ideas a form, and then putting those potential solutions into the hands of your end user or customer for early and frequent feedback.

Design Thinking Venn DiagramDesign Thinking is a set of mindsets (or what some in Agile might call “principles”) for solving problems that has been around for about 30 years — making it even older than Scrum. It came out of both the Stanford Design School (the d.School) and a leading design and innovation consulting firm named IDEO. Design Thinking exists at the intersection between what is viable for the businessfeasible in terms of available technology and desirable to consumers. In order for Design Thinking to work, people first need to develop a sense of creative confidence, a concept that Tom and David Kelley describe in detail in their book “Creative Confidence: Unleashing the Creative Potential in Us All”. In effect, they say that, rather than treating design as some sort of cult activity that is only done by a select set of highly specialized design clerics, everyone should focus on bringing out their own inherent creativity, especially in problem solving. To help this process along, organizations can promote Design Thinking so it can be absorbed into the DNA of the broader organization.

What Are the Key Mindsets (Principles) of Design Thinking?

Since its inception, Design Thinking has been anchored on six key mindsets. You’ll notice a lot of similarities between each of these six mindsets and the principles of the Agile Manifesto.

  • Focus on Human Values
    By developing empathy, we put ourselves into the shoes of the people for whom we are trying to solve a problem because that’s when we are able to develop a true understanding of their problem.
  • Culture of Prototyping
    The goal is to get feedback early by showing users prototypes instead of telling them what we think we are trying to create. Let’s fail fast when necessary so we can learn from the failure and try something else that might be more likely to work. In other words, we’re turning a concept into something more tangible — mens et manus!
  • Show Don’t Tell
    This mindset is very analogous to the Scrum review/demo where, at the end of each iteration, the team shows the PO the value they produced as opposed to just talking about their accomplishments with the goal of getting timely feedback that can inform the development process. It is essential to embrace feedback quickly (even on unfinished work).
  • Radical Collaboration
    In Design Thinking, the preference is for a cross-functional team of people with creative confidence participating in the design process and bringing in their own unique perspectives and areas of expertise.
  • Bias Toward Action
    Get everyone out of their cubes and whenever possible out of the building so you can observe real problems in real settings. This also means taking initiative, doing more and talking less, as well as making progress even when you feel stuck.
  • Focus on Process
    Finally, we want to iterate as much as possible, we want to be transparent in terms of our progress, and we want to encourage the team to reflect on process and improve it
Business Agility Ecosystem

Design Thinking can provide a mature and proven set of principles and practices that both the business/product management and software development parts of the organization can use to identify which problems are worth solving and very rapidly ideate potential solutions to those problems by using prototypes and testing assumptions. It can fill the gap that exists in many organizations that have successfully passed through the first and second waves of Agile and are looking for a set of practices to help them enter into the third wave of Business Agility. One approach to implementing Design Thinking toward achieving Business Agility is to view it in relation to the entire value stream. Consider the following diagram that shows a high-level visualization of an end-to-end Business Agility Ecosystem:

Business Agility Ecosystem-01 

In the first wave of Agile, we focused mostly on the middle space, and as a result this has traditionally served as the entry point for the discussion about the need for Agility. Agile team-level frameworks such as a Scrum, Kanban and Extreme Programming (XP) are frequently used today to help organizations build solutions using traditional Agile practices. However, as delivery speed increases, the need to address bottlenecks and obstacles up- and downstream have made Agile values, principles and practices more widely applicable. Design Thinking could be used as the foundation for the upfront part of a Business Agility Ecosystem — where the focus is on figuring out which problems to solve — either along with or as an alternative to other sets of practices such as Lean Startup.  As we get further along into the ecosystem, we can decide to implement some of these validated solutions by manifesting those ideas as backlog items on an Agile team’s product backlog in the middle space of the ecosystem. The final space of the ecosystem includes practices that enable the organization to deploy customer value quickly, such as DevOps. Meanwhile, the enterprise undergoing change must also have certain foundational approaches that make Business Agility possible: Change Management capabilities and frameworks, such as ADKAR or Kotter Accelerate; Agile portfolio management to support more Agile governance and risk practices, and scaling patterns (SAFe, LeSS, etc.) to establish Agility throughout the enterprise.


When we compare the mindsets of Design Thinking to the values and principles of the Agile Manifesto, it’s clear that there’s a lot of synergy and compatibility between the two, and this is why a number of organizations are already having success embracing Design Thinking as a key component of their overall Business Agility strategy. In “What is Agile?” Denning identifies a number of companies who have already achieved a certain level of Business Agility. Perhaps in the near future companies seeking to innovate at the pace of change could join these ranks by adopting some of the principles and practices found within Design Thinking to implement their own Business Agility Ecosystem.

Mens et manus!


Sources and Further Reading

Field Guide to Human Centered Design. IDEO. 2015.

Hasso Plattner Institute of Design. Introduction to Design Thinking PROCESS GUIDE. Stanford University. 2012.

Hasso Plattner Institute of Design. An Educator’s Guide to Design Thinking. Stanford University.

Kolko, Jon. Design Thinking Comes of Age. Harvard Business Review. Sept. 2015.

Roger Martin, Dean. The Design of Business: Why Design Thinking is the Next Competitive Advantage. Harvard Business School Publishing. 2009.

Denning, Stephen. “What is Agile?” Forbes. 2016.



Change management is a key element of any Agile transformation, but few people understand why it’s so important and how it fits in with Agile. To learn more about where change management and Agile transformations intersect, watch Dan Fuller’s webinar “Leading Agile Change: Proven Change Management Approaches for Agile Transformation” now.

Watch Now

The post Design Thinking and the Business Agility Ecosystem appeared first on SolutionsIQ.

Categories: Companies

Improved Insights into the Distribution of Work

Understanding the distribution of your team’s work can help you make better decisions about how work is...

The post Improved Insights into the Distribution of Work appeared first on Blog | LeanKit.

Categories: Companies

LINK: What is an Agile Manager?

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


This article, posted on Oikosofy’s blog, gives a pretty good introduction into the way things were in manufacturing and the way things are now. In “Agile-Manager — What is an Agile Manager?” he goes back to the time of FORD to explain how things have progressed.

It shows that not only have agile methods changed the way things are made, but they have also changed the corporate environment which houses the teams who make the products.

He also address how so many businesses now offer services and how that effects development.

I found this article insightful and worth a read.

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

The post LINK: What is an Agile Manager? appeared first on Agile Advice.

Categories: Blogs

Agile Aus – 5 sketches on a whiteboard

Growing Agile - Thu, 08/18/2016 - 14:58
5 sketches on whiteboards Glyn Thomas We attended this talk at Agile Australia where Glyn explained his process by doing 5 different sketches in real time. These are the types of sketches he does in meetings when he is trying to sell the value of design. Biggest learning here was to design for the experience […]
Categories: Companies

Groupthink and Fear as Team Killers: A Conversation with Marc Danziger

NetObjectives - Thu, 08/18/2016 - 13:43
Groupthink and Fear as Team Killers: A Conversation with Marc Danziger Marc Dangizer and Jim Trott talk about the problems teams often face when no one on the team is willing to acknowledge the challenge if others don’t (groupthink) or because they are afraid of what the consequences might be if they do (fear). In either case, the team is far worse off because issues get addressed only when they...

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

SonarQube 6.0 in Screenshots

Sonar - Thu, 08/18/2016 - 10:31

The SonarSource team is proud to announce the release of SonarQube 6.0, which features support of file renaming, and better UIs for admins at every level.

  • File move/rename tracking
  • Redesigned Quality Profile space
  • “My Projects” page
  • Redesigned Permissions UI
File move/rename tracking

For the first time ever, SonarQube can now track file moves – either to a new location within your project or (using the *nix definition of “move”) to a new name, and move the file issues with the files instead of closing the old issues and re-opening them as new issues at the new locations.

Now you can reorganize your packages without worrying about their old issues suddenly showing up as “new” again. In short, refactor away!

Redesigned Quality Profile space

Quality Profile administrators should also have an easier time starting with this version. First, this version helps you answer important questions about the rules in your profiles:

and plugins:

Its redesigned interface also makes managing profiles easier than ever:

The profile detail page offers further detail and management options:

“My Projects” page

As a project administrator, you’ll now have an easier time keeping an eye on the projects under your management. The “My Account” space now features a list of all the projects on which you have administration permissions, with at-a-glance reporting of project status:

Redesigned Permissions UI

Global administrators also get a new, easier to use UI for global and project permissions, and project templates:

Project permissions have been centralized under Project Administration, but you can still get there from the global level via the Actions menu in Project Management:

That’s all, Folks!

Its time now to download the new version and try it out. But don’t forget to read the installation or upgrade guide.

Categories: Open Source

Scrum Police Game now in Spanish!

Growing Agile - Thu, 08/18/2016 - 10:14
We have exciting news – thanks to Ángel Águeda Barrero from EvergreenPM the game is now available in Spanish
Categories: Companies

Agile Africa, Johannesburg, South Africa, August 22-23 2016

Scrum Expert - Thu, 08/18/2016 - 09:57
Agile Africa is a two-day conference for Agile and Scrum practitioners that takes place in Johannesburg, South Africa. Agile Africa is an annual conference where African software professionals meet to listen to leading international and local speaker discussing better ways of developing software. In the agenda of Agile Africa you can find topics like “Alignment at Scale”, “Attack Strategies for Taming Legacy Code”, “Exploring the Options with PopcornFlow”, “Making Retros Work”, “Leader transformation – a side effect of an agile transition”, “Fish ponds and Agile”, “Specification by example”, “Travelling light – The pros and perils of lean documentation”, “Behavior Driven develop your Agile Projects”, “Requirements Engineering for Agile Product Owners: Hunting Value with Structured Conversations”, “Product Owner Vision and Challenges: Managing Agile projects and organizational objective”. Web site: Location for the Agile Africa conference: Wanderers Club, 21 North Street, Illovo, Johannesburg, South Africa
Categories: Communities

Announcement: NEW Certified Scrum Developer Training!

Learn more about transforming people, process and culture with the Real Agility Program Reasons Why BERTEIG’s Certified Scrum Developer training stands above all other offerings:

  • Mike is an Agile and technical trainer who has been writing code for over thirty years
  • Berteig Consulting is the premier Canadian Agile services organization
  • team of coaches & trainers to support Mike
  • Excellent hands-on training: focus on participant simulations and discussions, no slides
  • Mike blends his strong technical background with a deep understanding of Agile methods to help teams consistently improve how they deliver value to their customers
  • Mike has been an active member of the Agile community for the last fifteen years (since the beginning)

Praise for Our Certified Scrum Developer (CSD) Training:

“Mike inspires you to want to improve your craft as an individual and as a team. You will learn skills to improve your development instantly, and skills that will allow you to continue improving every day.” – Developer – June 2016

“This is one of the best trainings I have ever had. Learned everything in real-time in much fun way rather than total theory. When taught with live examples, that create more impact. Mike is just so awesome in his teaching style.” – Front-end Developer – June 2016

“The course is very useful and it is relevant to our daily work. Exercises we did in the course helped to understand the agile/ scrum process a lot.” – Technical Specialist – June 2016

“I feel reinvigorated to take my job and team performance to a higher level.” – Developer, Feb-Mar 2016

“Mike is a great instructor and his details in explaining concepts and applying them during the training was a great learning experience.” – Developer, Feb-Mar 2016

“The class was incredibly beneficial to help illustrate the benefits of TDD, and improved code quality yields better productivity over time. It also helped emphasize Agile works best for Complex systems.” Senior Developer, Feb-Mar 2016

“The course was really interesting and helpful. Some of the topics were eye-openers. Would recommend to any SCRUM team member (developer or tester).” – Technical Consultant, Feb-Mar 2016

“This course gave a practical experience to most Agile development skills in a short period of time.” – Technical Specialist, Feb-Mar 2016

“This is a very good course for Scrum Developers as you can practise all learning on the spot.” – Scrum Developer, Feb-Mar 2016

“I loved this certification course! What I learned here would have taken lots of time to learn and observe in real life and now I know I can apply it into my job.” — Reynaldo 2015

“I really enjoy learning from Mike. He’s flexible and willing to listen for feedback to adapt his course/agenda to fit our groups needs. I’ve learned a number of topics relevant to what we do in our company and will definitely try them out.” — S/W Developer, November 2015

“I like the time I spent here. It was useful for myself as a software developer. I’ve learned several new techniques and technologies.” – S/W Developer, November 2015

“Opened a new window for doing my job.” – Developer, November 2015

“This was a very fun and useful course because it was delivered by an extremely experienced coach who is a developer. PS and he likes LEGO.” – Developer, November 2015

“Mike is an ‘agile’ trainer w/ for both technical and agile approaches.” – T, November 2015

SIGN UP FOR CERTIFIED SCRUM DEVELOPER COURSE HERE! Bonus #1: attendees get one free book from the list of recommended reading on Agile and Scrum topics. You select a book at the end of the course. The book will be shipped to an address of your choosing after course completion.

Bonus #2: attendees get free Planning Poker decks. Every attendee gets at least two. If you need more, please let us know when you register; if you are from a large enterprise company, we can ship you 100 decks at no charge!

Audience: This course is ideal for those who desire to create high-performance product development teams. Professional developers will gain tremendous understanding about Scrum’s amazing transformational power and the critical role of the Scrum developer. If you are a member of the Project Management Institute, this course counts for 40 PDUs (5-day) or 21 PDUs (3-day), and can be used as part of the requirements towards the PMI-ACP designation. Downloads:  CSD_logo_with_scrum_alliance.png Facilitator(s): Mike Bowler REGISTER NOW FOR THE CSD COURSE! Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!

The post Announcement: NEW Certified Scrum Developer Training! appeared first on Agile Advice.

Categories: Blogs

AutoMapper 5.1 released

Jimmy Bogard - Wed, 08/17/2016 - 22:28

Release notes here: AutoMapper 5.1

Some big things from this release:

  • Supporting portable class libraries (again), profile 111. Because converting projects from PCL to netstandard is hard
  • More performance improvements (mainly in complex mappings), 70% faster in our benchmarks
  • Easy initialization via assembly scanning

As part of the release, we closed 57 issues. With the new underlying mapping engine, there were a few bugs to work out, which this release worked to close.


Categories: Blogs

Retrospectives that Make a Difference

Kanbanery - Wed, 08/17/2016 - 20:27

Artykuł Retrospectives that Make a Difference pochodzi z serwisu Kanbanery.

Kanban teams are supposed to “make policies explicit.” I’ve asked at conferences, in forums, and on Twitter, “How do you make policies explicit?” I’ve never gotten an answer. I suspect many teams don’t have a good way of capturing and communicating policies.

Most policies come out of retrospectives. They address problems the team identifies. If you have a retrospective every two weeks, and in each one you make two or three improvements to your process, that’s a lot of changes. I’ve seen many teams forget good practices that used to work or keep doing something that doesn’t work long after everyone’s forgotten why they started in the first place. How do you remember which ones worked? How to decide which to keep, which to scrap, and which to tweak?

I’m a big fan of Big Visible Charts. I’ve covered my walls with information radiators. I’m also passionate about software quality. I’d like to share a QA process tool I created to make retrospectives more effective. It makes policies explicit and ensures that we remember to focus on what I think of as the “four dimensions of software quality.”

Most people think that software quality means no bugs. Ask most teams about quality practices and they describe finding and fixing bugs. Granted, the world would be better if we could find and fix the many bugs that live in our favorite software. But this is a tragically incomplete view of software quality.

The four dimensions of software quality that I’ve identified are these:

1) Well-structured, clean code with good test coverage which follows standard conventions and coding practices with clear style guidelines

This allows new people to join the team or for a product to be handed off to a new team. It makes it easy to add new features or to refactor code without breaking existing functionality.

2) An architecture that allows for efficient and appropriate scalability.

Not every web application is going to have to support millions of users. But just in case, the architecture should be such that migrating to cloud hosting or a distributed delivery model shouldn’t involve massive refactoring.

3) Quality software is delightful to use.

Features shouldn’t just work; they should work in a way that is intuitive and pleasant.

4) And finally, the features work.

Without awkward workarounds or … bugs. That doesn’t only mean that nothing is broken. It also means that the development team understood the problem and created an appropriate solution.

We don’t want to end up with a product that looks great, but doesn’t work, or works great, but doesn’t scale.

What you might notice is that in no place in this article have I referred to software testers or QA engineers. Software quality is the responsibility of everyone on a software team, and team quality practices reflect that. In my experience, all of the issues that arise in retrospectives directly impact one of the four aspects of quality. For example, poor communication with the product owner leads to improperly implemented features. Any change in policy that improves communication, makes the product better.

Using the chart

I’ve created a large wall chart to collect practices with four quadrants for each of the four dimensions of software quality.


If the team sits together in a room, you can print this chart onto A0 paper and post it on the wall. As ideas for process improvements come up in a retrospective, add them to the appropriate grid on a Post-it Note. These practices should be detailed enough to be consistently followed. Instead of “hallway testing” we might write “When a programmer has finished work on a feature, she asks someone who’s not busy to use the feature without guidance or prompting in an Internet Explorer environment before marking the feature as ready for a code review.” Making the rule specific in regards to who does what and when makes it less likely to be ignored or sloppily implemented. Start the next retrospective by reviewing the new policies. If they prove to be good ideas, we write them directly on the poster. If they didn’t work, the team can tweak them or scrap them and try something else.

Eventually you end up with a chart showing what policies the team has adopted to address each aspect of quality, as well as the experiments that the team is currently trying. If there’s an area of quality that’s not being addressed, you can see it clearly. If you have many teams, they can visit and see how other teams are addressing problems they may have and learn from each other.

But maybe your team isn’t co-located?

You can use an “Experiments” Kanbanery board to track your experiments and make your policies accessible. Use a different task type for each of the four types of quality, so you can tell from the rainbow of colors on your board that you’ve got all your bases covered.

The first column is for proposed experiments. The second is for experiments in progress, and the third is for Policies. If the Policy column gets too full, use four different columns so that you have a list of policies for each dimension of quality.

Failed experiments can be archived. Annotate them with comments about why they didn’t work, so you also have a collection of data about what didn’t work for the team and why.

You can also share the board with other teams. Or make it public so anyone can learn from your experiences and be inspired by your experiments.

How do you test the ideas that come up in retrospectives? How do you make policies explicit? Please share your ideas in the comments.

Click here to download the chart.

Artykuł Retrospectives that Make a Difference pochodzi z serwisu Kanbanery.

Categories: Companies

Announcement: David Sabine Featured in Human Code’s Blog

Learn more about transforming people, process and culture with the Real Agility ProgramTestimonial: Senior Agile Coach David Sabine

David Sabine 201504 - white background - head - 275 square

Recently, a Senior Agile Coach was interviewed by Human Code and the article was posted on their blog.

David and I took a few minutes to chat on the phone about his positive experience working with Human Code and what led up to the entertaining and inspiring article they posted.


David said that he had been hired for a two day training with a digital product development agency in Hamilton, Ontario. At the time, they were calling themselves Imagination Plus.  Since then they have changed their name to “Human Code” and this represents their embracing a new way of working and a new way of seeing themselves after training with David a few months ago.

David explained that Imagination Plus was a name that the founders thought of years ago. Over time, no one on the team really identified with it anymore. They did a workshop around this theme and they came to their collective realization that they do have an identity as an organization, but it’s something else than “Imagination Plus” so they went on a journey to find their identity. And the re-branding is a recognition of their new definition of themselves.

There are 17 people in the “tight-knit” company, David said.

“They are now announcing their new name and new logo, and they realized they wanted to go back to talk to me, to share my thoughts about agility and how that was part of their new identity now. They want to remain agile.”

“This is a positive testimonial not just for our training but we were involved in their transfomration. This is a story of transforming not from something to something else. Transforming from something else to a new thing. They transformed to authenticity.”

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

The post Announcement: David Sabine Featured in Human Code’s Blog appeared first on Agile Advice.

Categories: Blogs

Announcement: New Sessions Proposed for Toronto Agile Conference 2016

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

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

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

The post Announcement: New Sessions Proposed for Toronto Agile Conference 2016 appeared first on Agile Advice.

Categories: Blogs

Why Test-After Coverage Is Lower

Agile In A Flash - Wed, 08/17/2016 - 04:20

Unit testing after the fact? We do just enough test-after development (TAD) to please our manager, and no more.
Just Ship It! Once the business realizes they have product in hand, there's always pressure to move on to the next feature.
Invariably, any "after the fact" process is given short shrift. This is why post-development code reviews don't reveal deep problems, and even if they do, we rarely go back and make the costly changes needed to truly fix the problems. This is why after-the-fact testers are always getting squeezed out of the narrow space between "done" software and delivery. 
My Sh*t Don't Stink. I just wrote my code, and it works. I know so because I deployed it, cranked up the server, and ran through the application to verify it. Why would I waste any more time building unit tests that I hope to never look at again?
That Can't Possibly Break. Well, two-line methods and such. I can glance at those and think they look good. Lazy initialization? That couldn't break, could it?
That's Gonna Be a Pain. Holy crud, that's a 100-line method with 3+ levels of nesting, complex conditionals, and exceptional conditions (test those? you're kidding). It's going to take me longer to write a reasonably comprehensive set of tests than it took to write the method in the first place.

Worse, the method has numerous private dependencies on code that makes database or service calls. Or just dependencies that have nothing to do with what I'm testing. Just today I tried to instantiate a class, but failed because of a class two inheritance levels up with a dependency on another object being properly instantiated and configured. Figuring out how to test that is going to be a nightmare that eats up a lot of time.
Code written without immediate and constant consideration for how to unit test it is going to be a lot harder to test. Most of us punt when efforts become too daunting.---I hear that TAD coverage typically gets up to about 75% on average. Closer inspection reveals that this number is usually all over the map: 82% in one class, 38% in another, and so on. Even closer inspection reveals that classes with a coverage percent of, say, 38, often contain the riskiest (most complex) code. Why? Because they're the hardest to test.

If I was allowed to only do TAD and not TDD, I'd scrap it and invest more in end-to-end testing.

-- Jeff
Categories: Blogs

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

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


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.


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

The post Announcement: Mike Bowler’s CSD course – Spots Still Available appeared first on Agile Advice.

Categories: Blogs

Smalltalk-Inspired, Frameworkless, TDDed Todo-MVC

Matteo Vaccari - Tue, 08/16/2016 - 18:14

I wrote an alternative to the Vanilla-JS example of I show that you can drive the design from the tests, that you don’t need external libraries to write OO code in JS, and that simple is better :)

Why yet another Todo App?

A very interesting website is Like the venerable shows many different ways to render the same page with CSS, instead shows how to write the same application with different JavaScript frameworks, so that you can compare the strengths and weakness of various frameworks and styles.

Given the amount of variety and churn of JS frameworks, it is very good that you can see a small-sized complete example: not too big that it takes ages to understand, but not so small to seem trivial.

Any comparison, though, needs a frame of reference. A good one in this case would be writing the app with no frameworks at all. After all, if you can do a good job without frameworks, why incur the many costs of ownership of frameworks? So I looked at the vanillajs example provided, and found it lacking. My main gripe is that there is no clear “model” in this code. If this were real MVC, I would expect to find a TodoList that holds a collection of TodoItems; this sort of things. Alas, the only “model” provided in that example has the unfortunate name of “Model” and is not a model at all; it’s a collection of procedures that read and write from browser storage. So it’s not really a model because a real “model” should be a Platonic, infrastructure-free implementation of business logic.

There are other shortcomings to that implementation, including that the “view” has a “render” method that accepts the name of an operation to perform, making it way more procedural than I would like. This is so different to what I think of as MVC that made me want to try my hand at doing it better.

Caveats: I’m not a good JS programmer. I don’t know the language well, and I’m sure my code is clumsier than it could be. But I’m also sure that writing a frameworkless app is not a sign of clumsiness, ignorance or old age. Anybody can learn Angular, React or what have you. Learning frameworks is not difficult. What is difficult is to write good code, with or without frameworks. Learning to write good code without frameworks gives you incredible leverage: gone are the hours spent looking on StackOverflow for the magic incantations needed to make framework X do Y. Gone is the cost of maintenance inflicted on you by the framework developers, when they gingerly update the framework from version 3 to version 4. Gone is the tedium of downloading megabytes of compressed code from the server!

So what were my goals?
  • Simple design. This means: no frameworks! Really, frameworks are sad. Just write the code that your app needs, and write it well.
  • TDD: let the tests drive the design. I try to write tests that talk the language of the app specification, avoiding implementation details as much as possible
  • Smalltalk-inspired object orientation. JS generally pushes you to expose the state of objects as public properties. In Smalltalk, the internal state of an object is totally encapsulated. I emulated that with a simple trick that does not require extra libraries.
  • I had in the back of my mind the “count” example in Jill Nicola’s and Peter Coad’s OOP book. That is what I think of when I say “MVC”. I tried to avoid specifying this design directly in the tests, though.
  • Simple, readable code. You wil be the judge on that.
How did it go?

The first time around I tried to work in a “presenter-first” style. After a while, I gave up and started again from scratch. The code was ugly, and I felt that I was committing the classic TDD mistake, to force my preconceived design. So I started again and the second time was much nicer.

You cannot understand a software design process just by looking at the final result. It’s only by observing how the design evolved that you can see how the designer thinks. When I started again from scratch, my first tests looked like this:

beforeEach(function() {
  fixture = document.createElement('div');
  $ = function(selector) { return fixture.querySelector(selector); }

describe('an empty todo list', function() {
  it('returns an empty html list', function() {
    expect(new TodoListView([]).render()).to.equal('<ul class="todo-list"></ul>');

describe('a list of one element', function() {
  it('renders as html', function() {
    fixture.innerHTML = new TodoListView(['Pippo']).render();
    expect($('ul.todo-list li label').textContent).equal('Pippo');
    expect($('ul.todo-list input.edit').value).equal('Pippo');

The above tests are not particularly nice, but they are very concrete: the check that the view returns the expected HTML, with very few assumptions on the design. Note that the “model” in the beginning was just an array of strings.

The final version of those test does not change much on the surface, but the logic is different:

beforeEach(function() {
  fixture = createFakeDocument('<ul class="todo-list"></ul>');
  todoList = new TodoList();
  view = new TodoListView(todoList, fixture);

it('renders an empty todo list', function() {

it('renders a list of one element', function() {
  expect($('li label').textContent).equal('Pippo');

The better solution, for me, was to pass the document to the view object, call its render() method, and check how the document was changed as a result. This places almost no constraints on how the view should do its work. This, to me, was key to letting the test drive the design. I was free to change and simplify my production code, as long as the correct code was being produced.

Of course, not all the tests check the DOM. We have many tests that check the model logic directly, such as

it('can contain one element', function() {


Out of a total of 585 test LOCs, we have 32% dedicated to testing the models, 7% for testing repositories, 4% testing event utilities and 57% for testing the “view” objects.

How long did it take me?

I did not keep a scrupolous count of pomodoros, but since I committed very often I can estimate the time taken from my activity on Git. Assuming that every stretch of commits starts with about 15 minutes of work before the first commit in the stretch, it took me about 18 and a half hours of work to complete the second version, distributed over 7 days (see my calculations in this spreadsheet.) The first version, the one I discarded, took me about 6 and a half hours, over two days. That makes it 25 hours of total work.

What does it look like?

The initialization code is in index.html:

<script src="js/app.js"></script>
  var repository = new TodoMvcRepository(localStorage);
  var todoList = repository.restore();
  new TodoListView(todoList, document).render();
  new FooterView(todoList, document).render();
  new NewTodoView(todoList, document).render();
  new FilterByStatusView(todoList, document).render();
  new ClearCompletedView(todoList, document).render();
  new ToggleAllView(todoList, document).render();
  new FragmentRepository(localStorage, document).restore();

I like it. It creates a bunch of objects, and starts them. The very first action is to create a repository, and ask it to retrieve a TodoList model from browser storage. The FragmentRepository should perhaps better named FilterRepository. The todoList.subscribe(repository) makes the repository subscribe to the changes in the todoList model. This is how the model is saved whenever there’s a change.

Each of the “view” objects takes the model and the DOM document as parameters. As you will see, these “views” also perform the function of controllers. This is how they came out of the TDD process. They probably don’t conform exactly to MVC, but who cares, as long as they are small, understandable and testable?

Each of the “views” handles a particular UI detail: for instance, the ClearCompletedView is in js/app.js:

function ClearCompletedView(todoList, document) {

  this.notify = function() {

  this.render = function() {
    var button = document.querySelector('.clear-completed'); = (todoList.containsCompletedItems()) ? 'block' : 'none';
    button.onclick = function() {

The above view subscribes itself to the todoList model, so that it can update the visibility of the button whenever the todoList changes, as the notify method will then be called.

The test code is in the test folder. For instance, the test for the ClearCompletedView above is:

describe('the view for the clear complete button', function() {
  var todoList, fakeDocument, view;

  beforeEach(function() {
    todoList = new TodoList();
    todoList.push('x', 'y', 'z');
    fakeDocument = createFakeDocument('<button class="clear-completed">Clear completed</button>');
    view = new ClearCompletedView(todoList, fakeDocument);

  it('does not appear when there are no completed', function() {

  it('appears when there are any completed', function() {;

  it('reconsider status whenever the list changes', function() {;

  it('clears completed', function() {;

  function $(selector) { return fakeDocument.querySelector(selector); }

Things to note:

  • I use a real model here, not a fake. This gives me confidence that the view and the model work correctly together, and allows me to drive the development of the containsCompletedItems() method in TodoList. However, it does couple the view and the model tightly.
  • I use a simplified “document” here, that only contains the fragment of index.html that this view is concerned about. However, I’m testing with the real DOM in a real browser, using Karma. This gives me confidence that the view will interact correctly with the real browser DOM. The only downside is that the view knows about the “clear-completed” class name.
  • The click on the button is simulated by invoking the onclick handler.

If you are curious, here is the implementation of createFakeDocument:

function createFakeDocument(html) {
  var fakeDocument = document.createElement('div');
  fakeDocument.innerHTML = html;
  return fakeDocument;

It’s that simple to test JS objects against the real DOM.

All the production code is in file js/app.js. An example model is TodoItem:

function TodoItem(text, observer) {
  var complete = false;

  this.text = function() {
    return text;

  this.isCompleted = function() {
    return complete;

  this.complete = function(isComplete) {
    complete = isComplete;
    if (observer) observer.notify()

  this.rename = function(newText) {
    if (text == newText)
    text = newText.trim();
    if (observer) observer.notify()

As you can see, I used a very simple style of object-orientation. I do not use (or need here) prototype inheritance, but I do encapsulate object state well.

I’m not showing the TodoList model because it’s too long :(. I don’t like this, but I don’t have a good idea at this moment to make it smaller. Another class that’s too long and complex is TodoListView, with about 80 lines of code. I could probably break it down in TodoListView and TodoItemView, making it a composite view with a smaller view for each TodoItem. That would require creating and destroying the view dynamically. I don’t know if that would be a good idea; I haven’t tried it yet.

Comparison with other Todo-MVC examples

How does it compare to the other examples? There is no way I can read all of the examples, let alone understand them. However, there is a simple metric that I can use to compare my outcome: simple LOC, counting just the executable lines and omitting comments and blank lines. After all, if you use a framework, I expect you to write less code; otherwise, it seems to me that either the framework is not valuable, or that you can’t use it well, which means that it’s not valuable to you. This is the table of LOCs, computed with Cloc. (Caveat: I tried to exclude all framework and library code, but I’m not sure I did that correctly for all examples.) My version is the one labelled “vanillajs/xpmatteo” in bold. I’m excluding test code.

#locs td:first-of-type { text-align: right; } 1204 typescript-angular/js 1185 ariatemplates/js 793 aurelia 790 socketstream 782 typescript-react/js 643 gwt/src 631 closure/js 597 dojo/js 594 puremvc/js 564 vanillajs/js 529 dijon/js 508 enyo_backbone/js 489 typescript-backbone/js 481 vanilla-es6/src 479 flight/app 475 lavaca_require/js 468 componentjs/app 432 duel/src/main 383 polymer/elements 364 cujo/app 346 sapui5/js 321 vanillajs/xpmatteo 317 scalajs-react/src/main/scala 311 backbone_marionette/js 310 ampersand/js 295 sammyjs/js 295 backbone_require/js 287 extjs_deftjs/js 284 durandal/js 280 rappidjs/app 276 thorax/js 271 troopjs_require/js 265 angular2/app 256 angularjs/js 249 mithril/js 242 thorax_lumbar/src 235 chaplin-brunch/app 233 vanilladart/web/dart 233 somajs_require/js 232 serenadejs/js 226 emberjs/todomvc/app 224 spine/js 224 exoskeleton/js 214 backbone/js 213 meteor 207 angular-dart/web 190 somajs/js 167 riotjs/js 164 react-alt/js 156 angularjs_require/js 147 ractive/js 146 olives/js 146 knockoutjs_require/js 145 canjs_require/js 139 atmajs/js 132 firebase-angular/js 130 foam/js 129 canjs/js 124 vue/js 99 knockback/js 98 react/js 96 angularjs-perf/js 34 react-backbone/js Things I learned

It’s been fun and I learned a lot about JS and TDD. Many framework-based solutions are shorter than mine, and that’s to be expected. However, all you need to know to understand my code is JS.

TDD works best when you try to avoid pushing it to produce your preconceived design ideas. It’s much better when you follow the process: write tests that express business requirements, write the simplest code to make the tests pass, refactor to remove duplication.

Working in JS is fun; however, not all things can be tested nicely with the approach I used here. I often checked in the browser that the features I had test-driven were really working. Sometimes they didn’t, because I had forgot to change the “main” code in index.html to use the new feature. At one point I had an unwanted interaction between two event handlers: the handler for the onchange event fired when the edit text was changed by the onkeyup handler. I wasn’t able to write a good test for this, so I resorted to simply testing that the onkeyup handler removed the onchange handler before acting on the text. (This is not very good because it tests the implementation instead of the outcome.)

You can do a lot of work without jQuery, expecially since there is the querySelector API. However, in real work I would probably still use it, to improve cross-browser compatibility. It would probably also make my code simpler.

Categories: Blogs

Youth in Agile, Part 2: Two Eye-Opening Experiences in an Agile Work Environment

BigVisible Solutions :: An Agile Company - Tue, 08/16/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 Mia Rudd, an Economics and International Relations major at USC in California.



Two Eye-Opening Experiences in an Agile Work Environment


Mia Final-1Before interning at SolutionsIQ, I had never really worked in a professional environment and I had almost no idea what Agile was. However, this past summer I had the opportunity to immerse myself in an Agile environment through my participation in a Certified ScrumMaster course here at SolutionsIQ and my internship with the sales department. Working in such a collaborative and cooperative office was a much different setup than I would have expected for my first job. It has been such a great experience exposing myself to the Agile work space and I hope I can work in a similar environment after I graduate from USC. I wanted to share my thoughts on my summer of eye-opening experiences at SolutionsIQ.

Getting My CSM

My first introduction to Agile was through the two-day Certified ScrumMaster course that SolutionsIQ offers. Although the class is usually comprised of solely working-age men and women, I was one of five college students given the opportunity to participate. Many of the attendees commented on how great it was for such young people to be exposed to Scrum and to start absorbing Agile concepts. They really enjoyed hearing our perspectives, giving us advice and sharing their experiences of the workplace. I enjoyed working with an older group of people, a much different experience than I’m used to at school. It was interesting observing how different ages operate and learn, especially during team exercises.

As opposed to many of the students in the class, I had no previous exposure to any kind of work environment, so, to me, learning Agile seemed obvious and intuitive. A lot of the attendees had trouble grasping concepts that seemed simple to me. I think they struggled with Agile because they had been using “waterfall” for so long. After the first day, it was hard to understand why all companies hadn’t already implemented Agile and why people would spend so much time and money learning something so basic.

As we started working in teams, I realized barely anyone felt the same way I did. What was really surprising to me was the small group dynamic and lack of effective teamwork. I’m used to working with unreliable college students, so I was sure working with a group of successful adults would be much easier. But I was wrong: a lot of the adults I worked with didn’t want to be team players. Many of them were unable to commit and agree to team decisions, slowing down the team as a whole. Additionally, several of them wanted to cheat in order to finish our group work quicker. This concerned me and really got me thinking – if these working adults would cheat on a fake project for a CSM course, a class meant to teach them teamwork and collaboration, then how they do they approach their real jobs?

Although I’m not interested in software development, I was still able to gain a lot from the CSM course. The instructors (Bryan Stallings and Jeff Nicholls) helped me apply Scrum to my everyday life, especially regarding schoolwork. In fact, I learned that making a backlog of work can be beneficial for almost any project, from redoing your backyard, to planning a Thanksgiving dinner.

Making a backlog can be used for almost any project, even planning Thanksgiving
Click To Tweet

My favorite concept from the course was learning about Sprints. When I was younger, I always imagined workers being stressed-out and drained, often required to stay late nights and weekends to meet deadlines and catch up on overflow work. The Sprint makes so much sense: it allows for work to be done efficiently, while avoiding unnecessary stress and overtime. In Scrum, projects are broken up into smaller tasks, and the team works in Sprints to perform the tasks. It also gives teams a sense of accomplishment once each project is finished, which likely boosts optimism and morale.

I think students my age would enjoy the CSM course because it provides a good perspective on how a work place should operate. Few people I know are even aware of what Agile is, but taking the CSM course completely opened my eyes and made me realize that working in an efficient, beneficial and simple environment isn’t as hard to achieve as you might expect.

Working in an efficient environment isn’t as hard to achieve as you might expect
Click To Tweet

My Internship

Interning at SolutionsIQ was an incredibly valuable experience. Not only did I enjoy working in such a friendly and welcoming environment, but I was able to improve my communication and interpersonal skills in a professional setting.

The office is extremely interconnected. The departments blend together both physically, through the setup of desks, as well as socially, through the constant communication between people. Everyone knows one another and is constantly talking to each other and asking for feedback. I also really like the fact that everyone is treated the same — no one is clearly “above” or “below” anyone else. It’s far from an intimidating environment; in fact, it’s extremely comfortable and casual while still remaining productive. Everyone is working, but no one seems stressed.

My favorite project so far has been helping Renee Wright with event planning for Jeff Leach’s #SIQRoadtrip. Not only did I find campsites for Jeff to park his RV for the night, but I was also responsible for researching and organizing events and dinners all around the US, including a baseball game at Wrigley Field between the Chicago Cubs and the New York Mets. In addition, I compiled a list of the contact information and location of SolutionsIQ consultants so Jeff could easily organize his plans. It was a great experience communicating with Jeff and Renee, as well as the many event centers and restaurants I was in charge of contacting, especially since I’d love to be some form of event planner one day.

Not only were Jeff and Renee really easy to work with, but everyone I’ve had the opportunity to help has taught me so much. I mainly worked with the sales team, and they always made sure I understood the purpose of my work assignments and encouraged lots of questions before I began. They took the time to thoroughly explain projects, while simultaneously teaching me about the business world.


When I started my internship, I was unsure of what to expect and what others would expect from me, but because the SolutionsIQ environment is so social and friendly, it wasn’t hard for me to feel welcome immediately. The main takeaway I gained from this internship is improved communication skills. The constant emailing, video chatting and meeting with the other employees has really made me feel comfortable in a professional work environment. I used to take so long trying to decide how to respond to emails, worried I would say something wrong, but now it comes more easily.

In my opinion, the constant collaboration and feedback, as well as the general interconnectedness throughout the office provide the optimal work space for productivity. That’s why I’d love to work in an environment similar to that of SolutionsIQ after I graduate.

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

The post Youth in Agile, Part 2: Two Eye-Opening Experiences in an Agile Work Environment appeared first on SolutionsIQ.

Categories: Companies

Knowledge Sharing

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