In this post I will share how to unleash the power of individuals in your organization by inviting in the whole person. Below is the visual summary. People are powerful when we invite the whole person to work: spirit, heart, body, and mind. Key environmental ingredients are: safety, trust and valuing people as human beings. Your […]
As a software developer, technical skills are a must – they are absolutely necessary, but they are also not sufficient.
The reality of what we do is far more than just logic and processing and making computers do things.
If technical skills are required, but not enough, then what else is there? What’s the secret to being a far more effective software developer?
I have a problem. Despite teaching people and organizations how to organize their work effectively, how to prioritize, about the evils of multi-tasking and the importance of sustainable pace, I have never been able to get my own to-dos under control. By extension, my life has never really been under control either. So I often work late into the night, almost every night, and on the weekends as well.
I have experimented with the Pomodoro (I could never get myself to stop working after 25 minutes. I want something done before I can put it down) and Personal Kanban (post-its with waiting-working-done around the screen of my notebook (the problem wan't the WIP but the length of the backlog). The results of my attempts was always the same: I worked very hard, getting things done one after the other, but my work schedule always extended into the night and over the weekend.
An experiment with timeboxing tasks/goalsTwo weeks ago, a read an article on linked in, Critical Things Ridiculously Successful People Do Every Day, by Travis Bradberry. His first recommendation: "[F]ocus on minutes, not hours." Enter your program in your agenda. A light went on. If I am going to do something, the first question I must answer is when am I going to do it? Then I block the time for that activity. What happens if I don't have time for it? Either postpone it, don't do it, or cancel something else.
So I decided to try an experiment. For one week, I would schedule every major activity I needed to accomplish. From Sprint Planing for the SBC website, to quotes I needed to send customers, a talk I needed to prepare, to packing for my trip to the Scrum Gathering. Everything went into my calendar. Looking back on it today, I see that I had 30 individual items over five days. Only once did I schedule work into the evening.
What happened? The good news: Friday morning, when it came time to leave, my wife said, "it's time." I said, "OK," put my suitcase in the car, and off we went. On the way, she said to me, "I have never seen you so organized and ready for departure before a trip like this!". (And I hadn't even told her about my experiment!). I accomplished every major goal I set for myself that week (except one). And I had time to watch 4 hours of amateur Star Trek videos on you tube without feeling guilty! Wow.
The bad news. My estimates suck. It starts with the assumption that 30 minutes every morning is enough to deal with routine emails. So I had to deal with that.
Having a schedule in my calendar, and new goal starting half an hour from now, has proven to be an interesting attractor. It reminds me to focus my attention on the right thing. I can look at my calendar and see what I should be doing.
If I get to the end one time box, and the goal has not been achieved, I have to ask myself the questions, what do I do now? Do I keep working on my current goal? Or do I schedule the remaining parts for later? Or do I cancel or postpone the next goal?
Depending on the situation, I have already done all of these. Remember, I said there was one major goal I did not accomplish? Well, I got to the time when I was supposed to start it, but I was nowhere near finished the previous goal. I evaluated the importance of the two goals and decided that it was more important to finish the goal I that I was working on. So I finished it and dropped the other one (urgent but not important). So timeboxing individual goals enables me to prioritize and ensure that the most important things get done. After a week of this, I was pretty happy with my results.
What does this have to do with Scrum? For me, Scrum consists of 6 essential patterns:
- Inspect and Adapt at regular intervals
- Produce something that might be valuable at least once per interval
- Management leads and supports, and knows when to stay out of the way.
- The whole team solves the problem
- One voice speaks for the customer/maximizes the value of the work done
- A coach helps everybody achieve higher performance.
Inspect and Adapt at regular intervals.
Produce something that might be valuable at least once per intervalFirst, I have stopped calling it task planning. I allocate time to achieve a goal, not perform a task. So I keep focus on the fact that my work should produce value. At the end of a time box, I hope that the goal will have been achieved. If not, that is the moment to Inspect and Adapt. I allocate time in Pomodoros (units of 30 minutes, including a 5 minute break). Nothing takes less than one Pomodoro, and I never block more than 4 consecutive pomodori for a goal. Often I achieve my goal. Sometimes I don't. That is when inspect and adapt is really helpful!
The whole team solves the problemThis one is actually pretty easy. I am the whole team. Management leads and supports, and knows when to stay out of the way.I don't think this is really relevant in my context. I am basically a one person company. Not much of a management layer. :-)One voice speaks for the customer/maximizes the value of the work doneThis one is a bit tougher. Can I effectively be my own product owner? I think so, but I am going to keep an eye on this one. I started to set longer term goals by allocating time further in the future to achieve them. Aside from managing time I am not yet managing a formal backlog. A coach helps everybody achieve higher performanceIs it possible to be my own Scrum Master? I don't think so. An essential aspect of being a Scrum Master a Scrum Master is the independent perspective. On the one hand, I don't feel like I have systematic impediments. On the other, how do I know that I am focussing on the right goals? How do I know that I am working effectively? I think there needs to be second person involved.Next experimentsThis week, I will continue with the approach. I have also asked my wife to play the role of Scrum Master and I'd like to add a Sprint Planning/Review and maybe even a retrospective. Hmm, that means scheduling time for it...My Personal Scrum, v0.1How am I doing Scrum for myself?
- When I decide I want to achieve a particular goal, I also decide when I will work on it, and block that time in my agenda
- If I have no time to work on a new goal, I have to either postpone the goal, reject the goal, or reschedule or renounce another goal
- I strive to work on / that which is planned at any given time
- I know my estimates suck, so I leave slack in my agenda and forgive myself if things don't get finished when I hoped/expected.
- My agenda serves me, not the other way around. So if reality is different than plan, I adjust the plan to reflect reality.
This post is a walkthrough multiple definitions of digital transformation from multiple sources.
Digital transformation can be elusive if you can’t define it.
Lucky for us, there is no shortage of definitions for digital transformation.
I find that rather than use one single definition for digital transformation, it’s actually more helpful to look at a range of definitions to really internalize what digital transformation means from multiple angles.
Before you walk through the definitions, be sure to review Satya’s pillars for Digital Transformation so you have a simple mental model to work with.Wikipedia on Digital Transformation
Wikipedia has a simple explanation:
“Digital transformation refers to the changes associated with the application of digital technology in all aspects of human society.”
What I like about that definition is that it goes beyond pure business and includes all impact on society, whether it’s education, government, sports, arts, leisure, etc.Altimeter on Digital Transformation
Altimeter defined digital transformation from a customer-focused lens in their online report, The 2014 State of Digital Transformation:
“The realignment of, or new investment in, technology and business models to more effectively engage digital customers at every touchpoint in the customer experience lifecycle.”
What I like about Altimeter’s definition is that it’s outside in vs. inside out. The big idea is to leverage technology to adapt to your customer’s changing preferences. So if you “transform”, but there is no visible impact to your customers or to the market, then you didn’t really transform.Capgemini and MIT Center for Digital Business on Digital Transformation
Capgemini and MIT Center for Digital Business define Digital Transformation in Digital Transformation: A Roadmap for Billion-Dollar Organizations like this:
“Digital transformation – the use of technology to radically improve performance or reach of enterprises.”
While their definition may look simplistic, the power is in the data behind the definition. It’s a global study of how 157 executives in 50 large traditional companies are managing – and benefiting from – digital transformation.Agile Elephant on Digital Transformation
Agile Elephant defines digital transformation like this:
“Digital transformation is the process of shifting your organisation from a legacy approach to new ways of working and thinking using digital, social, mobile and emerging technologies. It involves a change in leadership, different thinking, the encouragement of innovation and new business models, incorporating digitisation of assets and an increased use of technology to improve the experience of your organisation’s employees, customers, suppliers, partners and stakeholders.”
While this definition may seem more elaborate, I find this elaboration can really help get somebody’s head into the digital transformation game.MIT Sloan’s 9 Elements of Digital Transformation
In The Nine Elements of Digital Transformation, George Westerman, Didier Bonnet and Andrew McAfee identify the key attributes of digital transformation:Category Items Transforming Customer Experience
- Customer Understanding
- Top-Line Growth
- Customer Touch Points
- Process Digitization
- Worker Enablement
- Performance Management
- Digitally Modified Businesses
- New Digital Businesses
- Digital Globalization
The nine elements are excerpted from their digital report, Digital Transformation: A Roadmap for Billion-Dollar Organizations. Here are quick summaries of each:
- Customer Understanding – Customer Understanding is where “Companies are starting to take advantage of previous investments in systems to gain an in-depth understanding of specific geographies and market segments.”
- To-Line Growth – Top-Line Growth is where “Companies are using technology to enhance in-person sales conversations.”
- Customer Touch Points – Customer Touch Points are where “Customer service can be enhanced significantly by digital initiatives.”
- Process Digitization – Process Digitization is where “Automation can enable companies to refocus their people on more strategic tasks.”
- Worker Enablement – Worker Enablement is where “Individual-level work has, in essence, been virtualized — separating the work process from the location of the work.”
- Performance Management – Performance Management is where “Transactional systems give executives deeper insights into products, regions and customers, allowing decisions to be made on real data and not on assumptions.”
- Digitally Modified Businesses – Digitally Modified Businesses is “finding ways to augment physical with digital offerings and to use digital to share content across organizational silos.”
- New Digital Businesses – New Digital businesses is where “companies are introducing digital products that complement traditional products.”
- Digital Globalization – Digital Globalization is where “Companies are increasingly transforming from multinational to truly global operations.”
Sidenote – George, Didier, and Andrew sum up the power of digital transformation when they say, “”Whether it is in the way individuals work and collaborate, the way business processes are executed within and across organizational boundaries, or in the way a company understands and serves customers, digital technology provides a wealth of opportunity.”Digital Business Transformation
I think it’s worth pointing out the distinction between Digital Transformation and Digital “Business” Transformation.
Digital Business Transformation is specifically about transforming the business with digital technologies.
There are many lenses to look at but in particular it helps to view it through the lens of business model innovation. So you can think of it as innovating in your business models through digital technologies. Your business model is simply the WHO (customers), the WHAT (value prop), the HOW (value chain), and your WHY (profit model.)
An exec from SAP at Davos said it well when he said “new business models are driven by different interactions with companies and their customers.”
In pragmatic terms, that means evolving your business model and interaction patterns to meet the changing demands of your customers all along your value chain. For example, consider how millennials want to interact with a business in today’s world. They want to learn about a company or brand through their friends and family on social networks and through real stories from authentic people, and they want access to services anytime, anywhere, from any device.
Another way to think about this is how many companies are learning how to wrap their engineering teams around their customer’s end-to-end journey to directly address the customer’s pains, needs, and desired outcomes.
Hopefully, this helps give you a good enough understanding to get going with your Digital Transformation and to understand the difference between Digital Transformation and Digital Business Transformation so that you can pave your path forward.
If nothing else, go back to the Altimeter Group’s definition of Digital Transformation,“The realignment of, or new investment in, technology and business models to more effectively engage digital customers at every touchpoint in the customer experience lifecycle.”, and use Satya’s pillars for Digital Transformation as a guide to stay grounded.Additional Resources
Digital Transformation: A Roadmap for Billion-Dollar Organizations, by Capgemini and MIT Center for Digital Business
The 2014 State of Digital Transformation, by Altimeter
The Nine Elements of Digital Transformation, by George Westerman, Didier Bonnet and Andrew McAfeeYou Might Also Like
May is right around the corner and you know what that means — Agile Amped is taking its traveling circus back on the road! This year May is all about the Lone Star State: Texas is plays host to our two biggest events this spring, Keep Austin Agile 2016 and Change Management Conference, where we will be bringing our unique blend of Agility and organizational change management expertise to a new and broader audience.Keep Austin Agile 2016
Austin, TX – May 26, 2016
SolutionsIQ is excited to be a media partner for Keep Austin Agile this year. That means we’ll be bringing you more of the most relevant and up-to-date industry news and concepts brought to you by thought leaders like Earl Everett. Earl sat down with Agile Amped recently to discuss, among other things, Scrum and the origins of the now quintessential Agile term, reaching back to his days as a legitimate rugby player participating in a high-performance team that leveraged scrums to plan out their plays. As we all now know, this huddle was the inspiration driving Ken Schwaber and Jeff Sutherland to co-opt the term for their new framework, the Scrum framework that we know and love. Earl also touched on why he is passionate about metrics in Agile organization. His session at the KAA2016 conference is called “Agile Metrics: Using Them for the Force of Good, Not Evil”.
SolutionsIQ’s own (seemingly ubiquitous) Steve Martin will also be reprising his popular session “Managers and the Land of the Lost”. Check out our Agile Amped interview with Steve! Meanwhile, SolutionsIQ’s Jason Kline and SolutionsIQ alum Chris Waggoner will be presenting “The ScrumMaster Dojo: Building a Scrum Master and Coaching Community of Practice”.
What’s really fun is that many of the speakers at Keep Austin Agile 2016 have already taken a turn in the hot seat with Agile Amped! Expect to hear great things from these thought leaders and super-Agilists:
- Pradeepa Narayanaswamy Has Discovered Pair Testing
- Chris Shinkle Isn’t Playing Around Anymore
- Walter Bodwell
If you want to keep up with Agile Amped, don’t forget to subscribe below!Change Management 2016
Dallas, TX – May 15 through 18
Change management is a necessary component of Agile transformations, so naturally we are excited to be expanding to this event. To understand a little bit about how Agile and organizational change management interact, overlap and (at times) collide, check out some of these popular posts from our own blog:
- Agile Adoption and the ADKAR Change Model
- Agile Adoption and Organizational Change Management
- Agile Change Management
- Why is it Called an Agile Transformation?
The Change Management conference will be an exciting experience, no doubt so check back here for more great content on the topic. Or get it real time by subscribing below now!
Be Unstoppable – Subscribe!
Agile Amped – all the greatest Agile content is within your reach. Subscribe now to receive instant email alerts when new podcasts are posted. Dino says do it – so do it.
Lisette Sutherland posted a podcast we recorded about geographically distributed agile teams. See Organize Your Distributed Team over on the CollaborationSuperpowers site.
We covered how you can think about your geographically distributed agile team:
- Why you want a distributed agile team (yes, there are some great reasons)
- How you might organize your team.
Here are the articles I mentioned:
I wrote about the timezone bubble chart in Managing Timezones in Geographically Distributed Agile Teams
Here are three posts about Geographically Distributed Teams Have Choices for Lifecycles about options for how you might do agile with a geographically distributed agile team.
I even had a chance to rant about management. We had a blast, as you can tell. Hope you enjoy it.
If you are having culture challenges with your organization, you are not alone. 80% of participants at a recent conference (Scrum Gathering in Orlando) reported that the dominant culture in their organization is not supportive of progressive working environment such as Agile. Where is Your Organization? The infographic below show my simplification of the Laloux […]
This week at VersionOne we had the opportunity to celebrate our CTO Ian Culling for having a birthday. He won’t tell us how old he is, so I guess that means he’s over 20? If you get the chance to meet him you might think he’s in his 20’s!
The man is a big part of the culture here at VersionOne. He makes things fun in addition to being smart as hell and doing a bang up job as the CTO. Walk into the development area and you are sure to find traces of Ian’s shenanigans, Dumb & Dumber orange suit, a plethora of nerf guns, Oculus rift, OneWheel, and more recently a Razor drift cart.
He’s also known for showing up at events in “special” attire. It’s a thing we that we’ve come to expect from him, but there’s always an element of surprise to it. So in honor of his birthday, we thought we would egg him on for an upcoming golf event that we have going on.
Below is the email that went out from Holly Reynolds, an interaction designer on the product development team.
In case you didn’t know…. it’s Ian’s birthday today…
We all know how much Ian loves to dress up and as much as he probably would like to come to work in his actual birthday suit, clothing is not optional here at VersionOne.
Stars pass and we honor them by celebrating their life after they are gone, but that seems like such a waste. Ian’s not dead, but he is getting older. Each of these remind me of him in a special way. I’m pretty sure if you pick your favorite, we just might get to see this guy show up at the upcoming golf outing on May 16th (don’t forget to sign up…you’re welcome Michelle).
Reply to me with your vote by 5 pm today or add your own suggestion for the birthday guy if you please.
The results will be compiled and shared later.
Creator, eccentric, minus the weird hair.
The Artist Formerly Known as Ian
Calm, cool and….collected;
Purple pants are not above this man
Rowdy Roddy Culling
“I came here to chew bubble gum and kick ass.
And I’m all out of bubble gum.”
Comment on this post and vote for your favorite or make a suggestion of your own. We’ll share the results in a couple weeks!
The post How We Celebrated Our CTO’s Birthday and How You Can, Too appeared first on The Agile Management Blog.
It’s always cool to see the work our team is doing around the world to help hack a better world.
Our Digital Advisory Services team is helping the Government of India, the Ministry of Human Resource Development (HRD), to reimagine the student experience and to develop India’s first MOOCs (Massive Open Online Courses) platform.
Apparently, the presentation went so well that the honorable HRD minister, Smriti Irani tweeted our Student Experience Journey Map that helps show the vision and the Digital Transformation opportunities.
Way to go!
Use this checklist of 11 goals to help you decide if your team is ready to graduate from a daily standup.
The post Daily Standup: Is Your Team Ready for the Next Evolution? appeared first on Blog | LeanKit.
In part one of this series of blogs on Understanding Cost of Delay and its Use in Kanban, we considered the meaning and definitions of Cost of Delay (COD) and Urgency (U). In part two we looked at Cost of Delay Profiles and the archetypes defined in Kanban for classifying work items. Now we look at the prioritisation/ordering technique know as Weighted Shortest Job First: the formula, the assumptions behind it and how the formula arises. WSJF brings the primacy of time into decision making about which item to implement and when.
Consider a product development team. They have many ideas for what to add or change in the product, and for improving the way they work. The question is, which of these many useful things should be done first. It turns out the that the total business value of an item is not the the deciding factor in maximising the business value a team can deliver in a given period; nor is it urgency (the Cost of Delay per unit of time). The deciding factor is the urgency divided by duration of implementation, a term sometimes referred to as the WSJF (or "wisjif") of the item.
To see why let's consider 2 work items with a value of V, a duration of D, and an urgency of U. Suffices will indicate which of the 2 work items is being referred to. Assuming the WiP limit in our team is 1 (so the team does only 1 feature at a time), and assuming the urgency, U, is a constant over the period of interest, the estimated value realized by the 2 features will be:
Total value arising from implementing Item 1 followed by Item 2
For more information see Essential Kanban CondensedThis is the present value of the two items less the cost of delay. In the case of the first item, the delay is just its own duration, but in the case of the second item, it must wait for the first item as well. If we want to know whether it is better to do item 1 first or item 2, we need to know which has the higher cost of delay. We can visualise the cost of delay like this... it is the total area in these graphs.
Switching the terms over in the formula above, and subtracting, gives us the cost of delay. Most of the terms cancel out but we are left with the following, for the addition benefit (cost if negative) of doing item 1 before item 2.
This gives us the basis of WSJF. To maximise business value delivered by the team, we should prioritise the items which have a higher value for urgency divided by duration.
In the next article in this series we will look at whether the duration used in this formula should be Customer Lead Time, System Lead Time or something else. This will lead us to conclude how the formulae can be used in practice, in conjunction with the cost of delay profiles for the items.
Read part 4 now: WSJF - Should you divide by Lead Time or by Size?
Back to part 1: Understanding Cost of Delay and its Use in Kanban
Since we love touring and meeting our community of users, we’re setting out on the road once again, this time to more cities than ever! Over the next 6 months you’ll be able to see us and ask any questions you have, in more than 10 cities in Europe and the US.
This year, we are very excited to return to the City Tour to share with you all the news around the SonarQube platform, and show you our latest product: SonarLint, which allows developers to track quality of their code in real time as they type it. Very powerful!
Here is what will be covered at each stop of the tour:
- The Leak Approach: a new paradigm to manage Code Quality
- SonarQube 5.x series in demo
- SonarQube integration to Microsoft ALM
- SonarLint, the missing piece of the puzzle
- Customer feedback
- Sonar Analyzers and well-established standards
- Roadmap for the platform
- Roadmap for Sonar Analyzers
It will also be a great opportunity to meet other SonarQube users to share tips and tricks and discuss your experiences with the platform.
Is there something you would like to know or ask us but haven’t had the opportunity to do so? Now’s your chance! Sign up for the free event in your preferred city, and we’ll see you soon!
Registrations are open on our website, so pick the city you want, fill the form and you’ll be all set.
Join the conversation by using #SSCT2016 in all your tweets about the events.
See you soon !
The older version of this was some variant of "Extreme Programming is just hacking" or "Extreme Programming is just cowboy coding".
In essence, the suggestion is that Agile is equivalent to "Code and Fix" or "Cowboy Coding".
Kent Beck describes the heartbeat of an Extreme Programming episode in response to the "Why is XP not just hacking?" question. Paraphrasing for length...
- Pair writes next automated test case to force design decisions for new logic independent of implementation.
- Run test case to verify failure or explore unexpected success.
- Refactor existing code to enable a clean and simple implementation. Also known as "situated design".
- Make the test case work.
- Refactor new code in response to new opportunities for simplification.
Granted, not every Agile team has this kind of technical discipline. Hence, so-called Flaccid Scrum and the advocacy of Two-Star Agile fluency.
Also, granted, that sometimes one should throw stuff together quickly when the purpose of the exercise is to test an experimental concept. For example, "spiking a solution" or an initial MVP.
It's the end of an era. After nearly 10 years of updates and lessons-learned, we’ll be removing Targetprocess v.2 following next month’s build. As we’ve explained in earlier posts, we’re doing this to help accelerate our development speed and make important improvements to Targetprocess v.3.
Most of our users are already on Targetprocess 3 and won't notice any difference. For those of you still using Targetprocess 2, this change means you’ll no longer have access to old lists, dashboards, or the Targetprocess 2 interface. Time sheets and custom reports will be preserved and migrated to Targetprocess 3.
If you need help transitioning to Targetprocess v.3 and training users, please do not hesitate to schedule a “Migration to Targetprocess 3” workshop.
Our last Targetprocess 2-supported build will be released in May 2016. All updates after this will not be compatible with v.2. If you absolutely don’t want to lose access to Targetprocess 2, let us know via firstname.lastname@example.org. We don’t recommend this option, but it’s your choice and we’ll take steps to help you keep your access to v.2. In this case:
For On-Demand accounts: We’ll move your account to a separate environment where you can continue working off of Targetprocess 2, but will no longer receive updates or new features.
For On-Site accounts: You won’t be able to upgrade your Targetprocess instance with any build released after May 2016. You can keep using Targetprocess 2, but with no new features or updates.
We’ve had some great times with Targetprocess 2, and we’ll always look back at it fondly. If you want to read the whole story behind the product, take a look at our company chronicles (2004-2014).
Let us know if you have any questions or concerns about this change. If you have any fond memories of v.2, we’d love to hear them in the comments. Now, it’s time for us to move on and look ahead to the future of Targetprocess. We hope to see fans of Targetprocess 2 there as well.
This is a popular variant of "Agile is fundamentally just..." and is similar to "Agile is just for programmers", differing only in not wanting to identify with "Agile".
Let's work through the reasoning.
When building something effectively, how do you know what is right?
In order to know what is right, you need to understand both the problem space (What problem are we trying to solve? What forces are in play? etc.) and the solution space (What options do we have? What trade-offs are in play? etc.).
Nominally developers have the best understanding and insight into the solution space. "Let the developers do what they think is right" implies that understanding the solution space magically means that you understand the problem space. This doesn't make any logical sense.
One-way communication from developers to product owners / managers is as illogical as one-way communication from product owners / managers to developers.
Bringing perspectives together in order to gain understanding and insight of both problem and solution space does make logical sense.
Doing what you think is right is ineffective if you have no justifiable reason for those beliefs.
See also Lean Startup.
Doing Agile and Being Agile are different. Here is a popular infographic that explains what Agile really is and illustrates common misunderstandings about it: Doing Agile Doing Agile is about the practices: standups, user stories, iterations, etc. There are significant benefits from using Agile practices – I see it as “common sense” of getting work done. […]