I discovered an amazing new concept the other day. A radical re-combination of things I thought were fixed and immutable. Two ideas that I loved by themselves, things complete without any addition. Things so familiar to me that I never dreamt of change. Frankly, I never saw the need. These ideas when put together created something greater than the sum of the two. Something so shocking that my first reaction was blank incomprehension. That’s right, I’m talking about: Fried Chicken and Waffles
I’ll give you a minute to sit down and let it sink in. Dinner and breakfast in the same meal! Two memes that complement each other so completely they create a larger meme! Sweet and savory, fried and…baked? Fried? Oh I don’t care. I love them both. So finding a restaurant that serves two of my favorite foods on the same plate, well, that’s pretty special.
That’s the way it is sometimes. Ideas that by themselves are great, but that are somehow magnified when combined with another idea. Somehow by repackaging them together we create something greater. Something that works much better as a whole. Of course there are plenty of culinary examples: french fries and poutine, caramel and salt, bacon and…um…well…anything.
Of course we have similar concepts in the software world. There are folks that maintain that the combination of some development practices yields disproportionate benefits as well. For example, combining agile and DevOps. Rapid development techniques and tightly integrated operations. The two make a potent one-two punch that provides powerful benefits to companies bold enough to adopt them. It’s like fried chicken and waffles.
Filed under: Uncategorized
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.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Link: Use Scrum Planning Meetings for Agile Delivery appeared first on Agile Advice.
SAFe has come a long way, not just in the development and refinement of the concepts and ideas, but in the sheer size and diversity of the community it serves.
I remember the first time we had anything resembling an ‘official’ SAFe meeting. It was with a smattering of folks in a small hotel suite at Agile2012 in Dallas. We were grateful that these brave early adopters saw so much potential in the Framework, and though we felt confident that we were on the right track, we really had no idea that just a few years later there would be nearly 60,000 professionals trained in SAFe, and over 70% of U.S. Fortune 100 enterprises adopting SAFe practices.
Now, with so many enterprises depending on SAFe to drive business results, there has been a growing—and loud—demand for an event dedicated to furthering the knowledge and practice of the Framework. Last year we dipped our toes in the water with a two-day Partner Summit. Over 100 Partner members came to Denver with their sleeves rolled up, ready to listen, learn, debate, and share ideas. The event proved to be productive and successful in a way that far exceeded our expectations, and we walked away with an understanding that the entire community, not just partners, would benefit from an event dedicated to SAFe.
So, I’m delighted to say that it’s happening. This October, we’re holding the first SAFe Summit in Denver, Colorado, open to the entire SAFe community: partners, practitioners, instructors, consultants, and enterprise business leaders. It will combine three key events:
—October 25, Partner Day: Dedicated to building Partner success in selling, supporting, and deploying SAFe products and services, the Partner Day is for Scaled Agile Partners’ business leaders and their associated SPCs and SPCTs.
—October 26–27, SAFe Summit: The two-day Summit will bring together SAFe practitioners, consultants, as well as Partners and enterprise customers. With multiple keynotes, tracks, breakout sessions, and enterprise success stories, this is a must-attend event for anyone who depends on SAFe to support their business or enterprise.
—October 28, SAFe Training Day: For certified SAFe Program Consultants (SPCs), and SAFe Program Consultant Trainers (SPCTs), the SAFe Training Day includes: Building Large and High Assurance Systems with SAFe 4.0; SPC Performance Toolkit for the Portfolio; SAFe 4.0 Course Delivery Enablement; Training SAFe 4.0 from the back of the room.
Session and Keynote topics include:
- SAFe: Past, Present, and Future
- Applying SAFe to Large and Complex Value Streams
- The Lean Portfolio Management
- Agile HR
- Enterprise Customers and their SAFe Journey
- Applying SAFe in a Project Delivery Environment
- Financial Aspects of Lean Portfolio Management with SAFe
- Implementing SAFe with a Structured Approach to Organizational Change Management
- SAFe in Government,
- Building Large and High Assurance Systems
- And more topics to be announced in the coming weeks
Early-bird registration is available until September 15 on the Summit website at safesummit2016.com, where you can also find the latest updates to the agenda, speakers, sessions, and venue.
We’re really excited about taking this next, important step in supporting SAFe and the community of practice, and hope you will be able to join us this October in Colorado.
I hope to see you there. Stay SAFe!
—Dean and the Scaled Agile team
Agile software ontwikkeling kent ingebouwde feedback. Iedere iteratie wordt afgesloten met een sprint review/demo en een agile retrospective, waarin feedback centraal staat. Ook tijdens de iteratie is er gelegenheid voor feedback. Een overzicht van de diverse manieren van feedback in agile en de voordelen die feedback oplevert. Product Demonstratie
De product demonstratie (sprint review in Scrum) is bedoeld om feedback te krijgen op het product. Een goede demo zorgt voor antwoorden op vragen zoals:
- Doet het product wat het zou moeten doen?
- Is het product bruikbaar?
- Welke functionaliteit is verder nodig?
- Wat kan er aan het product verbeterd worden?
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
In de agile retrospective reflecteert het team op hun proces. In de retrospective geven teamleden feedback naar elkaar. Deze feedback geeft inzicht in de manier van werken en helpt om continu te verbeteren.
Een goede retrospective geeft inzicht in:
- Wat ging er goed en wat heb je als team geleerd?
- Welke problemen zijn er geweest, wat zou je willen veranderen?
- Welke sterktes en kwaliteiten heeft het team?
- Hoe kan het team zich verder ontwikkelen?
Waardevolle Agile Retrospectives is het 1e Nederlandstalige Agile boek voor het faciliteren van retrospectives. Met vele oefeningen, het “wat” en “waarom” van retrospectives, de business value en de voordelen die retrospectives brengen. Tevens practische tips en adviezen voor het introduceren en verbeteren van retrospectives. Aanbevolen voor agile coaches, Scrum masters, project managers, product managers en facilitators die al enige ervaring hebben met retrospectives. Andere feedback momenten
De demo en retrospective zijn de bekendste feedback momenten in Agile. Maar er zijn er nog meer. Tijdens de dagelijkse stand up kunnen team leden elkaar feedback geven. Bijvoorbeeld over hoe ze de samenwerking in het team ervaren en hoe een activiteit gegaan is. In de planning game geeft het team feedback op de user stories naar de product owner, samen stemmen ze de inhoud van de iteratie af. Wat levert feedback op
Feedback in agile helpt om te leren en continu te verbeteren. De voordelen die feedback in agile oplevert zijn:
- Met frequente snelle feedback kun je eenvoudiger bijsturen
- Concrete feedback die kort na een gebeurtenis gegeven wordt, maakt eenvoudiger om actie te ondernemen
- Verbeteren in kleine stapjes is eenvoudiger, snelle feedback maakt het mogelijk.
- Goede feedback verbeterd de relatie tussen mensen en helpt om effectiever samen te werken
Agile wordt je door agile te doen. Wil je met agile resultaten bereiken dan is goede feedback essentieel. De sprint review/demo en de agile retrospective zorgen voor continue product- en procesverbetering, waardoor teams efficiënt en effectief producten kunnen leveren.
Op 21 september geef ik een gratis mini-workshop over agile retrospectives in Groningen. In deze mini-workshop gebruik ik oefeningen uit mijn succesvolle workshop Waardevolle Agile Retrospectives.
Retrospectives helpen je om agile effectief toe te passen continu te verbeteren. Je pakt ermee problemen aan en zorgt voor een goede werksfeer in je teams. Scrum masters en Agile coaches halen meer uit teams met behulp van een toolbox met retrospective oefeningen.
In deze mini-workshop geeft Ben Linders, auteur van het boek Waardevolle Agile Retrospectives, een introductie van de “waarom” en “wat” van retrospectives. Je oefent verschillende manieren om retrospectives te doen en krijgt tips en adviezen voor het introduceren en verbeteren van retrospectives.
Deze mini-workshop wordt gegeven in samenwerking met AgileHubNoord, een onafhankelijke netwerkorganisatie die als doel heeft om Agile-professionals uit Noord-Nederland met elkaar te verbinden, kennis met elkaar te delen en om het Agile-gedachtegoed onder de aandacht te brengen.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
Er zijn helaas geen plaatsen meer beschikbaar voor deze workshop (hij was in enkele dagen volledig “uitverkocht”), maar er is een wachtlijst. Als mensen zich afmelden word je automatisch aangemeld voor de meetup.
A new chapter which explores how visual management can be used to improve quality of software products has been added to my second book What Drives Quality.
One of the principles from agile and lean software development is transparency. Making things visible helps teams to decide what to develop and to collaborate effectively with their stakeholders. It can also help to increase the quality of software. You can apply visual management to make potential quality issues visible early and prioritize solving them. The examples that I provide explain clearly why quality matters and how visualization can be used to establish, maintain and even increase the quality of software products.
Retrospectives Exercises Toolbox - Design your own valuable Retrospectives
What drives quality provides insight into the factors that drive the quality software products and services. Understanding what drives quality enables you to take action before problems actually occur, thus saving time and money.
The book What Drives Quality is available for a reduced price on Leanpub as long as it’s under development. If you buy the book now you will automatically get all chapters that are added in the future for free. So don’t wait too long, get your copy now!
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!
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
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!
"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:
- Determine the types of behaviors to change based on current situation and the Agile transformation's business objectives.
- Determiner the roles impacted based on behaviors identified. Who typically has to exhibit these behaviors?
- Determine the org. units, processes, projects… to be involved in order to cover these roles
- Include the managers/executives and relevant subject matter experts in the transformation participants
- 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.
Previous: Apply the Agile transformation to real challenges, immediately (success factor 2)
Becoming 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.
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 :-).
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.
All 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:
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.
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:
- Dangers of Certainty in Realizing Customer Value
- How an Agile Customer Feedback Vision can lead to Customer Value
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.
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.
September 13 & 14, 2016
Who? Instructed by Senior Agile Coach Mike Bowler!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.
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.” –
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!
The post ANNOUNCEMENT: New Course Offering — Writing Defect-Free Code Faster! appeared first on Agile Advice.
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.
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!
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)Previous: Develop Agility for business reasons (success factor 1)