Agile Pain Relief Certified Agile Leadership (CAL)* Training — Giving leadership and management the tools and techniques to enable Agile within their organization
With the growing adoption of Agile, there is a need for a holistic approach for organizations to employ Agile throughout all aspects of business, rather than within specific teams. Expanding Agile methods from their traditional applications as development or product management tools into all areas of the organization requires a new set of skills in the management suite: Agile Leadership. Agile Leaders and Agile Leadership empower their organization from the top down to:
- Instill and practice Agile values, methods, and metrics at the organizational level
- Enable teams to deliver more customer value
- Remove barriers to team success
- Foster creative solutions
This three-day, hands on course led by Certified Scrum Trainer (CST) Mark Levison is targeted towards leaders, influencers, and managers within organizations that employ — or are planning to employ — Agile. Participants will learn core Agile concepts, processes, and practices, and how Agile can be used as a tool for organizational change to increase productivity and improve employee and customer satisfaction.The Agile Pain Relief Advantage Small Class Size in Your City Agile Pain Relief limits classes to a maximum of 20 students to ensure a quality learning environment with more opportunities to address your questions and concerns. Local training classes mean you meet and network with other professionals near you. On-site, private training also available. In-person and Interactive Direct learning tailored to each class and student. No canned PowerPoint presentations or webinars. Live instruction from Certified Scrum Trainers (CST) and group exercises modelled on Agile methods. Hands-on Applications of Scrum Methods with Agile Theory Practical examples and exercises using Scrum and Agile principles teach you how to adapt and practice Agile methods in your projects. Online Course Materials and Support Course attendees receive electronic copies of all seminar materials (including free updates to course materials as they become available) and exclusive access to Mark through Agile Pain Relief’s LinkedIn group.
** Courses available Q1 2017
I had such a great time in Wednesday’s webinar and was happy to have some questions to ponder on and share with the wider community. Here they are in no particular order:Q1: How do you prevent the colony from generating businesses that the enterprise doesn’t want to be in or that are not part of its core strength or interests?
A1: One thing we didn’t cover in the webinar is a concept called an Innovation Thesis, which is a tool that provides a vision for the range of ideas your Innovation Colony is interested in supporting. The Innovation Thesis describes an area of the market that you’ve identified as having growth potential over a particular time period (e.g., the next 5 years) and summarizes the beliefs that drive your decisions to incubate a particular idea, invest in a certain company, or acquire a certain startup. Your Innovation Thesis is a filter for opportunities; without it, your portfolio risks drifting out of alignment from your target market. A solid thesis can also inspire people to generate ideas that you want to capitalize on.
Many investors use a similar tool known as an investment thesis, which is essentially the same thing. For example, Union Square Ventures states it invests in “large networks of engaged users, differentiated through user experience, and defensible through network effects.”Q2: What if the innovations that come out of the colony cannibalizes your core business?
A2: First, consider that disruptive innovation doesn’t start out as a competition for an existing market. Disruptive innovations tends to start with an ignored or non-existent new market. It’s not until this new market becomes more developed that today’s customers may abandon an existing solution for the new solution.
Secondly, and more importantly no business survives the long term without reinventing itself. If you don’t disrupt your own business, someone else will, eventually. You have to be open to disrupting yourself before the competition does it for you.Q3: What about Intraprenuership programs? Can they work as an alternative to creating a whole other department?
A3: No, not for the sort of disruptive innovation the Innovation Colony is designed to generate. Typically, Intraprenuership programs only offer a portion of an employee’s time (for example, 10%), which is enough to get new ideas started and perhaps portions of the business model validated, but not enough find true product-market fit and grow a successful new business. Often an intrapreneur has to “sell” any new products ideas to heads of existing business units, and these managers aren’t motivated to do what it take for them to succeed, they don’t have much skin in the game, and often suffer from the “Not created in my backyard” syndrome.Q4: Can’t the disruptive innovation happen inside the existing org?
A4: No, most enterprises are filled with antibodies that prevent disruption from within. They are not geared to rapidly “search” for and discover new viable business models, let alone allow them the space and time to gain any legs to actually succeed. Enterprise product development functions are geared to keep resources focused on “execution” and growth of the existing products and business models, and the protect from disruption. The “search” vs “execution” modes are fundamentally at odds with one another, so the environment of the Innovation Colony provides must be completely separate from the product development organization.
—Missed the Webinar?
If you missed Jeff’s webinar “Innovation Colonies: Cultivating the Future of Your Business”, you can still watch it. Click the link below to learn all about the business benefits of establishing a healthy innovation colony and what makes them so powerful in driving disruptive innovation.Watch Now
The post Business Cannibalism, Intrapreneurship and Innovation Colonies – Webinar Q&A Follow-up appeared first on SolutionsIQ.
For the last month or so, we (ScaledAgile,Inc.) have been going though our 2017 planning strategic planning process, adhering as strictly as possible to SAFe guidance.
We’ve established the strategic themes, vision and budgets for our two primary value streams: framework and courseware. In so doing, we also needed to establish the KPIs which define the expected results and returns from each value stream.
In a parallel manner, a question we often get in response to the “no project-cost accounting” approach of Lean-Agile budgeting is “how do we know we’re getting a return on our investment for the funding for each value stream.” That’s actually the same question we’ve described above.
Based upon this learning, we’ve added some lightweight guidance to the value stream article, mostly a reminder to help ensure we all do our job as fiduciaries of the value stream investment. The new guidance is also linked from the metrics article.
Always be SAFe,
In our experiences working with teams around the world, in different industries, with different goals, we’ve found...
A conversation with SVP, Senior Consultant Marty Bradley about how developer maturity plays a role in forming software development teams.Hey Marty, so what’s the difference between a programmer, developer, engineer or consultant?
To me the biggest distinction is that developers don’t do things more than once. For example, one of the first things we try to get a team to do is move towards at least a daily build. Initially they will have to do it manually. What will happen with a developer is that once they have done that once or twice a night they get tired of it. Then they will sit up all night, download the free software and get the builds going. Then if the builds are breaking they will begin to manage the fact that the team isn’t following the process. Eventually the whole team starts to come up a level.
We are seeing more and more now that we have to drive that automation in by coaching or forcing them to do that.So why do you think it’s not sticking, why people are doing it?
When I was brought up as a developer, they sat me down with a senior level guy who showed me how to write code. He told me “You don’t write a piece of code twice.” He would give me situational things and review my code as I built it every day and talk to me about development best practices. My stuff would work. It’s easy to get it to work. But it’s hard to refactor on the fly. There’s a practice called legacy rescue or dojos, which is a practice we are starting up, where basically we pair up senior level developers with the team to work side by side. This moves the development of the application forward and gives the in-house team the deep level of training that you need as a developer in order to be more efficient, building better quality code.A lot of organizations think they have senior level developers, how do you think companies should go about assessing whether or not someone is a senior developer?
I think you should start by looking at technical debt. If you have a lot of technical debt and you’ve had a senior developer that has been on that team for a year or a couple of years and they aren’t doing something to take care of it. That looks like a problem to me. Now maybe the problem is that he is so senior that all the problems go to him and the other programmers aren’t doing much. So you have to free those guys up. Now this is the problem that we get into when we look at utilization instead of throughput. If you take your senior guys and give them a little bit more slack time they could spread themselves and their knowledge across the team. But what we have a tendency to do when we are in trouble is we give all the work to the one guy who we know will get it done. These are they types of things that we try to solve by going to team based development. We pair, we do things to help the senior developer free his time up.If you were talking to an executive how would you express how this is impacting them?
You can show over time to the executives the amount of defects that can be decreased by refactoring that code. It’s well documented that technical debt causes slower lead time to completion, increased manual testing time, and lower quality code.
I once went into a team where every time we made a change to a webpage it seemed to filter through and then other problems would pop up even through the webpage seemed fairly well isolated. When we went back and looked at it what happened was that the next page that had a problem was 90% the same with a slight modification. What that usually indicates is that someone needed to do something specific, for a customer perhaps or add a new feature, and instead of figuring out how the page worked they just duplicated the page made the change and everything was fine because nothing had changed in the system. Once you changed the original page you have to remember to go back and change the second page. When you have 6 web pages like that, where everytime you make a change you have leaking defects through out the other pages that no one can figure out.So how do you help these teams grow?
We take teams and teach them how to add refactoring into their development process and their estimates. When you write the first piece of code it’s hard to think in objects, which is a lot of the reason we want test driven development so that it forces you to think about the interfaces and the design. If you don’t start by learning test driven development you just don’t head down that path. So what we do is take teams that have been doing things this way and we pair them with a team. While they are helping them build the code they are teaching them ways to refactor. As a result the teams get a deep learning that they were never taught in school and the one-on-one mentoring that they need.Another topic that everyone wants to know. How do you get QA integrated into the team? Not just on the team but fully integrated into the team.
To me QA has to be involved from the very beginning with requirements. We talk a lot about behavior driven development and test driven development. The QA people tend to look at the problem differently, so if we get them involved up front and talk about the edge cases they’re concerned with or the big problems they see in the system once it gets deployed you start to train the developers to look out for that. Then the QA people become more analysts helping to drive the requirements the right way. A good stand up would be where a developer says he is working on some certain code and the QA person jumps in and notices that he will need test data. Not only that but the QA person can get them recent test data they need complete with the edge cases that the QA person wants included. Over time they will integrate themselves into the team and things begin to flow a bit easier. When this occurs you won’t hear the team talk about “QA people” it’ll just be “the Team.”
- Sponsored: 64% off Code Black Drone with HD Camera
Our #1 Best-Selling Drone--Meet the Dark Night of the Sky!
In this webinar, I’ll share my experiences with helping teams communicate the value of Kanban in a way that makes sense to management.
Release v.3.10.4 provides a helpful new user type for users doing cross-project collaboaration. As opposed to the Observer user type, who has read-only access to all public projects and teams in the system, Contributor users are allowed to edit. Contributors can modify any entity in any project or team which they are not a member of (if their default role allows these entity changes).
User type can be changed by admins at the Account Settings tab of a user's details view.
- Added batch updates for multiple selection Custom Fields
- You can now create a new entity as a Relation to a batch of cards
- Added a warning popup and confirmation safeguard for users trying to initiate a Process change from a Project view
- /api/v1/authentication?login=System requests will show a message if user still has a default password
- Disabled browser auto-fill for user details views
- Fixed a failure to assign teams to projects (or project to teams) for users with corresponding permissions in a team (or a project)
- Fixed the layout of inner lists in entity details views
- Fixed a case where the 'Work hierarchy' tab would show no data on some Projects' views
- Fixed entity convert failures for users that are both project members and observers
“Sometimes we get so caught up in what should be that we miss the beauty of what is.” – Doc Norton
At the 8th Annual Agile Conference, held in Toronto, Ontario last week, the keynote speaker Doc Norton presented some insightful ideas on Host Leadership, about the roles people take when initiating, launching and facilitating new ideas. The basic premise of having a Host Leader mindset is to be fluid with the needs of the environment. While there is a time and place for authoritative decision-making, otherwise called gate-keeping in Host Leadership lingo, there is also a need for a humble approach to supporting an idea from conception to fruition without clinging to hard-and-fast expectations about what must happen.
In his example of applying these principles, he shared how his family decided to host a Euchre game to create an opportunity to meet new neighbours. When something different than expected emerged, he experienced the value detaching from “what he wanted it to be” and accepting “what was becoming.”
In brief, here are the 6 key aspects of Host Leadership.
- Initiator – The person that provides the initial spark. A new idea.
- Inviter – Extends the invitation to people who may be interested in the idea. Who to invite and who not to invite.
- Space Creator – Those who create the physical and emotional space for those in attendance to feel safe, to learn, and to engage in the opportunity.
- Gate Keeper – Defines and protects the space which is created. Lets people in and out as necessary or appropriate. People who enforce the rules, doing interviews and hiring. Note: there is a right balance for this where there is not too much gate-keeping but just enough to create the right boundaries.
- Connector – Brings people together. They are conduits for information. They are typically the ones who know how things get done.
- Co-participator – Team leads participating in a retrospective as equals.
Sometimes the Host Leader sets and reinforces rules, but sometimes they serve others. This depends on the moment and context.
Doc Norton laughed at his own story when he revealed that even though he and his wife put lengthy effort into creating “Euchre Night” he discovered that in the basement a large group of guests started playing poker. Rather than becoming disgruntled about the change, he adapted and became a co-participator. As a result of letting what was becoming just be, the neighbours found themselves carrying out Poker nights monthly for a decade.
Host Leadership is about creating space for great things to emerge and surrendering the inclination to control the outcome.
These six items are aspects of roles of everyone on a team and shouldn’t be thought of as one person per role per team. Instead, when people on a team ebb and flow around these roles the thought-processes and discoveries can be shared with the team, and the growth on the team supports the initiatives for team members.
What were his concluding words of wisdom to the audience?
He said, “Consider your leadership role at work. Regardless of your title, think about what you are initiating. How do you extend invitations? What space are you creating and maintaining? When are you gate-keeping? How are you connecting with others? How are you joining what is emerging even if it is different than what you expected?”
The take away from this inspiring opening address was the optimistic message that what is becoming may be better than anything anyone could have hoped for.Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
The post Doc Norton introduces Host Leadership at 8th Annual Toronto Agile Confernce appeared first on Agile Advice.
Even after attending 2-day trainings for both ScrumMaster and Product Owner certifications, the real significant difference between ‘project’ and ‘product’ didn’t emerge, for me, until becoming a Product Owner of a Weekly Care Package. That’s when the deep learning began. I hope by sharing some learning here, other new (or old) Product Owners might consider the shift in thinking around working with products rather than working on projects.
When first agreeing to formally launch and support a social action initiative to provide fresh food weekly to a neighbour who is experiencing financial hardship, I could easily see how food could be collected, packaged and delivered in weekly increments. As a Product Owner, I would oversee what items came into the package and ensure everything was delivered on time. Reaching out to a few friends, neighbours, and colleagues resulted in dozens of people contributing to the package consistently over a period of a month. Surprisingly, approximately $400 was also donated. Without a doubt, the first iterations proved there are interested contributors and also a grateful recipient.
Interestingly, an experienced Agile trainer & coach, took notice of my efforts. He offered some advice, as a ScrumMaster might share with a new and fledgling Product Owner. In a half-hour conversation, he counselled me on some features of agile product development. He shared a few meaningful links with me, and after reminding me that Product Owners work with products, not projects, he invited me to return to an article I had written on the initiative.
I followed his guidance and when returning to my piece I found the word “project” used about half a dozen times, speckled through the article. Clearly, even though I was consciously creating a product called ” a weekly food package,” still I was unconsciously thinking of the initiative as a project. When I modified the article to insert “product,” then the way I saw the work also changed.
As a project, each time I deliver the package, the work is done. Project complete! As a product, which is a part of a delivery model called Scrum, it means each time a package is delivered it is then time to reflect in a retrospective. It’s time to learn and plan for next week’s delivery.
A project, in my mind, requires a lot of advanced planning, designated role assignments, accountability reports, and status updates. It requires a start date and a date of completion. ***
My new understanding of product development, which emerged from watching this Myths of Scrum video and reading this is that action can begin even with minimal planning. Interested people volunteer as they wish to support the development. No one reports to anyone or assigns tasks to anyone. When a successful iteration is complete, it’s useful to come together to talk about how it went and apply learning to the next week’s product.
With this learning, I later said to the ScrumMaster who was coaching me, that “I don’t see any reason for “projects” because when the focus is around a “product” then the quality is just so much better.”
In his wisdom he replied, “Imagine how it feels to Project Managers to hear something like that and you will then understand why this is such a hot topic in the industry.”
“Yes,” I replied. “I get it.”
(Michael Caspar recently tweeted about this Scrum-based social action initiative. You can read the article he shared at this link.)Learn more about our Scrum and Agile training sessions on WorldMindware.comPlease share!
Here’s an interesting problem our team faced last month that was extremely infuriating. We were in the process of launching replacement…
We’ve been using terraform at Zapier for over a year now and recently I was adding a new feature and looking over our large collection of…
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]