Cloud, mobile, social, and big data are changing the game of business.
But to play the game well, leaders need to grow new skills.
In order to create new customer experiences and market-leading operational capabilities, leaders need to invest in digital skills.
Our Cloud-First, Mobile-First world provides unprecedented possibilities in terms of connectivity and compute resources for changing customer experiences, transforming the workforce, and transforming operations, and creating new business models. Companies every day are building amazing solutions that integrate Cloud, Mobile, Social, and Big Data capabilities as well as what the Internet of Things brings to the table. But to take advantage of these capabilities, you need leaders that grow and invest in a digital platform and in digital skills.
In the book, Leading Digital: Turning Technology into Business Transformation, George Westerman, Didier Bonnet, and Andrew McAfee, share how top leaders grow their digital skills.Creating Great Customer Experiences Requires New Skills and New Ways of Working
Whether you want to reimagine your customer experience, or reimagine your operations, it takes new skills, and new ways of working. Companies that don’t have the right digital skills struggle. Worse, everybody is competing for the same skills, including social media analysts, mobile marketers, cloud architects, and data scientists.
Via Leading Digital:
“Creating great customer experiences or market-leading operational capabilities is more than technology challenge. It's also an organizational challenge requiring new skills and new ways of working. Yet, 77 percent of companies in our first year of research cited missing digital skills as a major hurdle to their digital transformation success. To compound the problem, most companies are chasing after similar skills--social media analysts, mobile marketers, cloud architects, or data scientists, to name a few.”How Digital Masters are Building Skills
If you want to help your company become a Digital Master, or, if you want to be a high-performing leader, you need to invest in digital skills.
Via Leading Digital:
“So what are Digital Masters doing differently when it comes to skills? First, they are investing. Of the Digital Masters we surveyed, 82 percent are building the digital skills they need to support transformation efforts. Only 40 perce3nt of nonmasters are doing so.
Second, Digital Masters are accelerating and creating a gap. Our survey research shows that the masters had greater digital skills than nonmasters, reporting 31 percent higher social media skills, 38 percent higher mobile skills, and 19 percent higher analytics skills.
But Digital Masters did not start with higher skills. Burberry did not become excellent at digital marketing. and channels overnight. CEO Ahrendts hired a new, dynamic marketing team whose members mirrored the behaviors of the millennial customer. Nor did Caesars excel at delivering personalized customer experience solely because its CEO, Gary Loveman, has a PhD in economics from MIT. Caesars' executives actively incorporated quantitative skills into the marketing area. In these companies, like other Digital Masters, top executives worked hard to build the digital skills they needed.”The Line Between Technical Skills and Leadership Skills is Blurring Fast
The gap is huge but the lines blur fast. There is a huge demand for people that are both business savvy and technology savvy.
Via Leading Digital:
“The skills difference extends beyond technology. Digital Masters report 36 percent higher skills in digital leadership than nonmasters. Digital transformation requires changes to processes and thinking--changes that span your internal organizational silos. 'The clear delineation between technical skills and leadership skills in blurring fast.
The impact of digital technologies is now felt not only in the IT and technical departments, but also across the entire organization. Digital transformation's need for cross-functional collaboration creates a huge demand for hybrid digital skills-- technical people who need to be more business savvy and businesspeople who need to be more technology savvy. A retail executive explained: 'We are trying for the first time to work across the company. That implies going through a new level of complexity in the organization, and requires people to manage and network differently. That, I think, is the most important skills that needs to be developed.'”Successful Leaders Will Have Business and Technical Skills
True hybrid professionals will be the leaders of tomorrow.
Via Leading Digital:
“The need for new skills can also result from the need to bridge the communication gap between digital and business competences. One executive said, 'I need a charismatic quant--somebody who's an influencer and can carry his weight in a senior meeting, but at the same time, someone who can roll up his sleeves and look at data tables and build models and enjoy it.'
These bridging roles may soon become the responsibility of every manager. 'I believe,' said Markus Nordlin, CIO of Zurich Insurance, 'that the successful leaders of tomorrow, in any business or industry, are going to be true hybrid professionals who have spent some time in IT but have shifted to operations and vice-versa.'”Digital Skills Create Competitive Advantage and Enable Digital Transformation
To keep up and get ahead, you need to master Digital Skills and be able to use them in a business savvy way.
Via Leading Digital:
“Aspiring Digital Masters are all chasing the same technical skills. The shortage of digital skills is unprecedented. In Europe alone, forecasts point to nearly a million vacancies for IT-related roles by 2015. And globally, out of the 4.4 million big-data jobs to be created by 2015, only a third will be filled.
But by the same token, business professionals will increasingly need to be comfortable with digital tools and technologies to perform their core roles. By 2015, research firm IDC expects that 90 percent of all jobs will require IT skills. Some business functions are already adding technology skills to their mix. Gartner reports that 70 percent of the companies they surveyed have a chief marketing technologist to support the digitization of the function.
This skills race won't slow down anytime soon. Having the right digital skills is an important source of competitive advantage and a key enabler of digital transformation. Companies that build skills faster will get ahead.
To win at the digital skills race, you will need to tap into multiple approaches--hiring, partnering, incubating, and the like. It's not easy, as one executive explained: 'Our recruiters don't know where to go to find these people, and people with the right skills don't look to our kind of company for opportunities.' HR organization will need to get up to speed quickly. A recent Capgemini Consulting survey found that only 30 percent of HR functions were actively involved in digital skills development. This needs to change. Many Digital Masters have a carefully crafted plan to fight and win the talent race.”
All of the capabilities of Cloud, Mobile, Social, and Big Data are right at your fingertips.
Using these capabilities in meaningful ways takes a combination of business and technical skills, as well as great organizational change leadership skills.
If you can master business skills and combine them with great technical skills, you can lead you, your team, your organization, and others to change the world.You Might Also Like
There was an article on Techcrunch a couple days ago which was linked in our internal mailing list the other day, titled The Rise And Fall Of The Full Stack Developer. I read it, and I just couldn't figure out why the title is about "the fall" of the full-stack developer (and I said as much on the mailing list, after which I was encouraged to write this blog post). In this post I'll try and explain why it's not the end, but just a stage in a recurring cycle
What I read was a waveform - the article describes that first you had low-level assembly, which is specialised but still pretty straightforward since it's just one platform and language. Then things started to get more complicated, with the larger web applications involving lots of experts in various fields (Java, database management, server and JVM management, to name a few from the article).
But, as the article states, that isn't the full stack of today - added to that are things like machine learning, mobile development, more advanced and less traditional programming languages, frameworks and persistence solutions, etcetera. The conclusion of the author is that it's too much for one full-stack developer to take, that there's no way a full-stack developer can be an expert in all of those fields - and he basically renames the person that knows a bit of all of those technologies a full-stack integrator, and declares the full-stack developer dead.
But I didn't see that. What I saw was just history repeating - from simple and manageable, to complex and too much for one person to handle and know all about. From assembly and PHP, to Java enterprise software and Docker-contained AWS instances running a MongoDB and Scala REST interface to power your Android, iOS and single-page AngularJS-powered webapps (to name but a few buzzwords).
I'm sure the next 'simple' wave is already around the corner - maybe it's already here, lurking somewhere until some more influential guy goes "Hey guys, let's go back to the simpler, good old times where you wrote code and it Just Worked™!", where a wave of developer will follow - most likely a combination of younger people, new to the software development world, and older people that have been stuck in an overly complicated software development rut for far too long.
As for not being able to keep up with it all, this is why it's probably better to assemble teams out of T-shaped developers - full-stack developers with a broad knowledge set (and more importantly, broad interests and curiosity), but with at least one specialisation. This was extended within Xebia to pi-shaped developers, then made extreme to comb-shaped developers, but the latter is just a generalist like mentioned in the article - a jack of all trades, master of none. And it's important to realise, as a developer, that it's OK to not know everything, to miss some update, to not learn that fancy new programming language by people disgruntled by Java's slow development - there's simply too much information updates today, and trying to manage it all in the extremest forms can lead to serious problems. But the rapid development is a good thing, I might add, I don't think the software development world has ever moved as fast as it does today, and it's not nearly the end yet as long as more than half of the world's population doesn't have access to the internet and its boundless resources.
I think increasing complexity is just part of software development. I mean look at Facebook and Twitter - they were started using those simple, accessible tools like PHP and Ruby on Rails, which allowed them to get a flying start and adapt quickly to their huge growth (and with the former desperately clinging to their decision, despite lots of people telling them they should use a different technology), but despite that they still turned into some of the most complicated pieces of software ever. The important bit is to be able to manage all that, not so much a decision between a simple or complicated toolset - or having all of your developers know everything. Similarly, the current trend is microservices - again back to simple, one-purpose miniature applications that do one thing and do them right. But those will just end up being the next generation of huge, complicated software systems, given enough time. As a colleague stated, "Microservices are just hipster SOA".
As the saying goes, the more things change, the more they stay the same. The full-stack developer isn't dead and won't be going away any time soon, he'll just go by a different name depending on the times - J2EE Certified Software Engineer, full-stack developer, multidisciplinary expert, T-shaped developer, Xebian, chief of technology evangelisation, or whatever else the HR or marketing departments of the near future will come up with.
Sustainable pace is all about keeping positive energy flowing on your teams. It doesn’t mean taking it easy. It doesn’t mean struggling to achieve a constant pace. It means expending your energy in a positive way, on the right things, for the right amount of time. It means allowing you and your team to feel the exhilaration of completing valuable work. And it means stopping at the right time to allow that exhilaration buoy your team along so they can all reach the finish line together.
This week, I was re-reading one of my favorite books called “What I Talk About When I Talk About Running” by Haruki Murakami. It’s not a book about business, agile, or lean product management. It’s actually a memoir written by an amazing novelist about running and training for marathons. And every time I read this book, I always find this passage the most interesting, especially for lean or agile teams:
“Right now I’m aiming at increasing the distance I run, so speed is less of an issue. As long as I can run a certain distance, that’s all I care about.” Sometimes I run fast when I feel like it, but if I increase the pace I shorten the amount of time I run, the point being to let the exhilaration I feel at the end of each run carry over to the next day. This is the same tack I find necessary when writing a novel. I stop every day right at the point where I feel I can write no more. Do that, and the next day’s work goes surprisingly smoothly. I think Ernest Hemmingway did something like that. To keep on going, you have to keep up the rhythm. This is the important thing for long-term projects. Once you set the pace, the rest will follow. The problem is getting the flywheel to spin at a set speed – and to get to that point takes as much concentration and effort as you can manage.”
Murakami doesn’t use the specific words, but he is describing what the lean and agile world refers to as sustainable pace. Lately, I’ve seen far too many organizations forget that sustainable pace is an important component of lean and agile systems. They push too hard, for too long and in the end sacrifice the health and well-being of their team members, and produce lower quality products. Sustainable pace allows teams and individuals to remain healthy, produce higher quality products, and to be more predictable in their output.
So, let’s break down Murakami’s quote and see if it helps us understand sustainable pace a little better.
“Right now I’m aiming at increasing the distance I run, so speed is less of an issue. As long as I can run a certain distance, that’s all I care about.” To me, this is the definition of done. My team knows the deal, knows what we have to deliver, and that we will get to done. Speed is not always the most important thing. Sometimes high quality and getting the right things done are more important than how fast something gets to market.
“Sometimes I run fast when I feel like it, but if I increase the pace I shorten the amount of time I run, the point being to let the exhilaration I feel at the end of each run carry over to the next day. This is the same tack I find necessary when writing a novel. I stop every day right at the point where I feel I can write no more.” I don’t believe that sustainable pace means a constant pace. The Agile Manifesto states, “Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.” I think sustainable pace needs to allow for the natural flow and ebb of energy through a team and through individuals. As Christoph Baudson describes it, sustainable pace means that work should happen dynamically by expending energy and then restoring it by the use of rituals. Stop and slow down at the right times so you and your teams can experience the exhilaration of the work they have done and let that carry on to the next day, sprint, or release.
“To keep on going, you have to keep up the rhythm. This is the important thing for long-term projects. Once you set the pace, the rest will follow.” While I don’t believe sustainable pace equals constant pace, I think it does imply a natural rhythm. If we are running a marathon, we can’t continuously run record setting sub-4 minute miles. It’s not a rhythm anyone could keep for 26.2 miles. You’ll bonk after a mile or two and never complete the race. But how do you know what pace you should run to complete a marathon? Or, how do you and your team know what the correct pace is to complete a project and remain healthy and happy? It’s trial and error. Try a pace that your team agrees to. Run a sprint or two. Do a retrospective. Were we running too fast? Too slow? Just right? Ask the questions, get the answers, and adjust your pace until it feels right for everyone.
“The problem is getting the flywheel to spin at a set speed – and to get to that point takes as much concentration and effort as you can manage.” Getting to a predictable pace is not easy. It takes a lot of effort. And it depends heavily on complexity. In terms of running, it depends on the terrain you are covering. Most road races are relatively flat, on pavement, with fairly predictable conditions. I know that when I run a road marathon I can run at a fairly fast pace. However, I also race a good deal of off-road trail marathons, and the pace I maintain in those races is significantly slower. Trail races throw a variety of conditions at you that can change dynamically…uphill, downhill, rolling, steep, rocky, sandy, wet, muddy…you name it, it’s out there. It takes a lot more effort and concentration to find a sustainable pace on the trail than it does on the roads. In the same way, it will probably take less effort for you and your team to get to a sustainable pace on less complex work than it will on more complex work.
So remember to expend only the right amounts of energy to get the right things done. Slow down or stop from time to time to allow your teams to restore that energy and enjoy the exhilaration of completing valuable work. Experiment with a variety of paces until your team finds a natural rhythm that works for them. And know that your pace does not need to be constant. Allow it to ebb and flow depending on the terrain of complexity. Run your teams at a sustainable pace and I promise you’ll not only reach the finish line, but you’ll feel great on the entire journey.
The post What Can Haruki Murakami Teach Us About Sustainable Pace? appeared first on LeadingAgile.
If you've scaled Agile across multiple teams, then you're likely doing regular sprint planning and you’ve developed a predictable cadence for releasing software.
Getting your teams to run like a well-oiled machine is all well and good, but the real value of scaled Agile comes from aligning your development and release cycles to your organization’s business priorities. You might have an important market event — a meeting or industry conference — driving a release deadline. What if your operations group is doing a system-wide upgrade, and you need to schedule a release around it? Maybe you’re shutting down your offices over the winter holidays and need to work that into your planning.
When it comes right down to it, what you build doesn’t have business value until you deliver it to the end user. So if your delivery schedule is tied to important events, you need to be able to include these events in your development planning and tracking.
The Scaled Agile Framework (SAFe™) refers to this as “Develop on Cadence, Release on Demand.”
Rally’s new milestones feature allows you to easily plan, track, and steer your work to both your development cadence and key internal or external events. With milestones you can link stories, features, or whole releases to a particular date: a market event, a trade show, or an important code deployment.How Milestones Work
Milestones help you coordinate work across teams to deliver the right work at the right time, and let you see how work is unfolding in alignment with a key market deadline. Milestones also give executives and other stakeholders immediate, realtime visibility into your progress toward your business priorities.
Imagine, for example, that you want to release a shopping cart feature with four components in time for Black Friday, one of the biggest shopping days of the year. You’ll want to track your progress on the four components and make sure they’re all coming together on-time, so you can release the feature as planned. If one of the components isn’t on track, you’ll know from watching your Black Friday milestone whether your feature release is at risk.How to Use Milestones
You’ll find the milestones page under the plan tab. When you create a milestone, you’ll give it a name and a target date, and you’ll choose which projects are linked to it.
You can link multiple work items to a milestone all at once, using bulk actions.
When editing the detail page for any item — a story, feature, defect, etc. — you can see the milestone(s) associated with that item.
You can also view milestones in the portfolio timeline. Click on the milestone icon to see the milestone’s name and date.
To see all the work associated with a particular milestone, select the filter button from the portfolio timeline page or the milestones page.
When you associate a work item to a milestone, you implicitly associate all the child items of this work item. For example, say you connect a feature to a milestone: you won’t see the milestone indicated on the child stories under the feature, but when you’ve completed all the child stories that roll up to that feature, then the feature will indicate that the milestone goal is met. Alternately, say you’ve got 10 child stories under a feature, but only 5 of them are associated to a particular milestone. In this case you’ll want to link these 5 stories directly to the milestone, rather than linking the milestone to the feature.Chart Your Progress Against a Milestone
In the same way you might watch stories or releases, you can create a burnup chart against a milestone, too.
You can also chart your development cadence against specific milestones to see how they map up. On the chart below you’ll see that the milestone for “2.0 Private Beta” (represented by the dotted line) does not align with a program increment boundary.
Ensure Your Highest-value Work Hits Critical Market Windows
Do you have important deadlines, events, or releases across your organization, and need to get everyone aligned to them? Create and track milestones in Rally and you’ll automatically connect your most important development work to the critical windows your business needs to hit.
In Rally you’ve got all the support you need to develop on a predictable cadence, AND release on a market-driven demand. Using milestones can ensure that your organization is not only building the right things, but delivering them when your customers and the market need them most.
Learn more about high-performing Agile at scale with Rally Program Launch.Shannah Van Winkle
I have previously suggested that effective Tech Leads spend an ideal minimum of 30% of their time writing code. A common question I hear in the Tech Lead training course I run is:
Where do I find the time to code when I have all these other responsibilities to take care of?
I know that many Tech Leads struggle to find the right amount of code, and also struggle to know what sort of tasks to take on. Here are some useful bits of advice that have helped me and others:Avoid working on critical path items
Although Gantt charts have a bad name in IT, they do serve a useful visual model for depicting critical chains and seeing the critical path. A Tech Lead will usually find themselves interrupted and finding a solid block of coding time will be unusual. As a guideline, I advise Tech Leads not to focus on critical path tasks because they will often block progress on those tasks.
If a critical path item requires knowledge or experience, that only the Tech Lead has, it is useful to work with another developer on the task, so that progress continues when the Tech Lead works on responsibilities.Learn to delegate
Delegating is a skill that Tech Leads must develop, and a skill that developers rarely have an opportunity to build. The Situational Leadership Model clearly explains when to delegate. Effective delegation depends on the skill and motivation of an individual. The model explains four modes: Telling, Selling, Participating, Delegating with the end goal of aiming to delegate as much as possible.
Delegating is only possible when a leader believes someone has the sufficient skill and sufficient motivation to complete a task.
A common challenge for many Tech Leads is trusting that someone other than them writes code good enough to complete an appropriate task.Loosely pair program
I’m not a big believer in full time pair-programming. But finding the right balance between full-time and nothing is hard to achieve. A good arrangement is to work with someone on the approach or design for a particular problem, and then to do regular reviews (or short pair-programming sessions) to see what new information or challenges emerge as code is written.
This style of “co-working” on the design and code works well for a Tech Lead, who will find themselves constantly interrupted.Avoid unnecessary or poorly run meetings
There is nothing worse for a programmer to sit in a meeting which has no purpose or no outcome. These are frustrating because the time spent in the meeting is waste. Learn how to run effective meetings, to avoid the frustrations of ineffective meetings.
Use the “5 P’s of Effective Meetings” model:
- Purpose – Is it clear what the meeting is for? Ensure each meeting has one clear purpose. Examples include: Distributing information, gathering information, brainstorming solutions, and seeking agreement or consensus.
- Product – You can cut a meeting short, when you know what the outcome of that meeting should be. Define success criteria for the meeting (which will be related to purpose) to keep meetings focused and on track.
- Participants – It is better to cancel/reschedule a meeting than to hold a meeting with the wrong people. This tweet from Esther Derby summarises it very well.
- Probable Issues – What are the concerns or questions that will be raised during the meeting that need to be addressed, or threaten to derail the meeting?
- Process – Every meeting should be clear about how the meeting will be run, how people are expected to participate, and special rules of what might need to be done. A meeting facilitator should start with clarifying the purpose of the meeting to reset people’s expectations.
The art of leadership is saying no, not saying yes. It is very easy to say yes. — Tony Blair
As a Tech Lead, you will be pressured to always take on more than you can possibly take on. The more activities you say yes to, the less time a Tech Lead has to code. If coding is really important to you (and it should be), then you need to develop an awareness of what things are really important and those that can be done by others or by non-technical people.Block out coding time
I know some Tech Leads who block out calendar time in their diary on a regular basis to ensure that they have uninterrupted time to code. Developers know how interruptions break the train of thought and Tech Leads will find themselves even more interrupted in comparison to developers.Conclusion
It is important a Tech Lead spends time writing code but the other responsibilities demand time away. Keeping the balance right is tricky, but the techniques described above can help you cutting code. Please leave a comment if you have other suggestions.
Man streitet sich immer wieder darüber, was Scrum eigentlich ist. Ist es ein Management-Framework? Oder doch ein Mindset? Oder gar eine Projektmanagementmethode? Vielleicht doch eher ein Prozess? Für mich ist es all das und noch viel mehr: nämlich auch eine Methode, um Probleme ans Tageslicht zu bringen. Durch die Transparenz, die in Scrum-Projekten gegeben ist, kann man Risiken und Hindernisse schnell erkennen und darauf (hoffentlich) frühzeitig mit einer Lösung reagieren.
Doch wie stellt man diese Transparenz in Scrum eigentlich her? In den unterschiedlichsten Projekten versuche ich stets, das gesamte Produkt bzw. Projekt an einem Ort haptisch abzubilden, um einen kompletten Überblick zu bekommen. Und ja, wir reden hier von Flipcharts, Brownpaper und Post-Its an der Wand. In diesem Blog möchte ich einen kurzen Überblick über eine für mich optimale Form eines „Projekt Cockpits“ geben.
- Transition Backlog und Taskboard für das Transition Team
- Skaliertes Impediment Backlog und Taskboard für das ScrumMaster Team
- Product Backlog und Taskboard für das Product Owner Team
- SoS Board und Release Burn-Down Chart für die Dev.Teams
All diese Boards, die man in der skalierten Scrum-Umgebung typischerweise vorfindet, würde ich an einem Platz zusammenhängen. Je nachdem, wie die Teams strukturiert sind und ihre Meetings leben, kann man die Reihenfolge der Boards anpassen, gewisse Boards zusammenlegen oder überhaupt andere Boards nutzen. Ob man die Wände eines Büros, eines Ganges oder eines Aufenthaltsraumes nutzt, ist letztendlich egal – wichtig ist nur, dass es ein zentraler Ort ist, damit die Macht der Transparenz über die Lieferung auch wirklich genutzt wird.
Am besten ist es, wenn jedes Team sein Board selbst gestaltet und sich überlegt, wofür es dieses nutzen möchte, welche Informationen darauf abgebildet sein sollten und wie es gepflegt werden wird. Generell bedarf es hier eines Commitments und der Mitarbeit aller Projektbeteiligten.
Einer der wesentlichen Benefits von Scrum ist die verbesserte Kommunikation innerhalb von Projekten und Organisationen. Dieses Projekt Cockpit verbindet Kommunikation mit Transparenz auf zwei Arten: Erstens wird hier die erledigte Kommunikation abgebildet (z.B. Impediments aus dem ScrumMaster- bzw. Tasks aus dem Transition Team Daily werden aufgeschrieben und aufgehängt) und dadurch entsteht eine Art Protokoll für die restlichen Mitarbeiter. Zweitens passiert es regelmäßig, dass jemand dort einen Task oder ein Impediment vorfindet, bei dem er selbst schon einmal etwas gemacht hat bzw. das er lösen könnte, wenn er nur davon gewusst hätte. Im Sinne der Nutzung von Synergien und Lieferung kann einem Projektteam doch nichts Besseres passieren!
Kleiner Hinweis: Anfangs dauert es meist ein wenig bis das Cockpit ins Laufen kommt, doch wenn es dann von allen genutzt wird, hilft es ungemein. Probiert es doch mal aus oder habt ihr selbst auch schon (andere) Erfahrungen mit dieser Art von Projekttransparenz gemacht?
Zum Schluss noch ein Beispiel-Cockpit aus einem aktuellen Projekt:
Over the weekend I was playing around with dplyr and had the following data frame grouped by both columns:
> library(dplyr) > data = data.frame( letter = sample(LETTERS, 50000, replace = TRUE), number = sample (1:10, 50000, replace = TRUE) ) > data %>% count(letter, number) %>% head(20) Source: local data frame [20 x 3] Groups: letter letter number n 1 A 1 184 2 A 2 192 3 A 3 183 4 A 4 193 5 A 5 214 6 A 6 172 7 A 7 196 8 A 8 198 9 A 9 174 10 A 10 196 11 B 1 212 12 B 2 198 13 B 3 194 14 B 4 181 15 B 5 203 16 B 6 234 17 B 7 221 18 B 8 179 19 B 9 182 20 B 10 170
I wanted to add an extra column which would show what percentage of the values for that letter each number had.
If we wrote that code standalone we’d have the following:
> data %>% count(letter) Source: local data frame [26 x 2] letter n 1 A 1902 2 B 1974 3 C 1911 4 D 1948 5 E 1888 6 F 1975 7 G 1914 8 H 1886 9 I 1910 10 J 1924 11 K 1974 12 L 1891 13 M 1894 14 N 1946 15 O 1956 16 P 1934 17 Q 1865 18 R 1992 19 S 1946 20 T 1854 21 U 1919 22 V 1913 23 W 1928 24 X 1934 25 Y 1908 26 Z 1914
We can also get that value by summing up the individual (letter, number) pairs from the previous data frame. The ungroup function allows us to do so:
> data %>% count(letter, number) %>% ungroup %>% group_by(letter) %>% mutate(sum.n = sum(n)) %>% head(20) Source: local data frame [20 x 4] Groups: letter letter number n sum.n 1 A 1 184 1902 2 A 2 192 1902 3 A 3 183 1902 4 A 4 193 1902 5 A 5 214 1902 6 A 6 172 1902 7 A 7 196 1902 8 A 8 198 1902 9 A 9 174 1902 10 A 10 196 1902 11 B 1 212 1974 12 B 2 198 1974 13 B 3 194 1974 14 B 4 181 1974 15 B 5 203 1974 16 B 6 234 1974 17 B 7 221 1974 18 B 8 179 1974 19 B 9 182 1974 20 B 10 170 1974
In my continued work with R’s dplyr I wanted to be able to group a data frame by some columns and then find the maximum value for each group.
We’ll continue with my favourite dummy data set:
> library(dplyr) > data = data.frame( letter = sample(LETTERS, 50000, replace = TRUE), number = sample (1:10, 50000, replace = TRUE) )
I started with the following code to count how many occurrences of each (letter, number) pair there were:
> data %>% count(letter, number) Source: local data frame [260 x 3] Groups: letter letter number n 1 A 1 184 2 A 2 192 3 A 3 183 4 A 4 193 5 A 5 214 6 A 6 172 7 A 7 196 8 A 8 198 9 A 9 174 10 A 10 196 .. ... ... ...
I wanted to find the top number for each letter and with a bit of help from Stack Overflow I ended up with the following:
> data %>% count(letter, number) %>% filter(n == max(n)) Source: local data frame [26 x 3] Groups: letter letter number n 1 A 5 214 2 B 6 234 3 C 8 213 4 D 6 211 5 E 9 208 6 F 2 219 7 G 1 213 8 H 2 208 9 I 9 220 10 J 7 213 11 K 3 228 12 L 2 206 13 M 3 212 14 N 4 222 15 O 1 211 16 P 7 211 17 Q 9 210 18 R 5 224 19 S 2 211 20 T 9 204 21 U 8 217 22 V 6 220 23 W 2 213 24 X 2 214 25 Y 3 211 26 Z 3 206
Here we’re filtering over a collection of rows grouped by letter and only selecting the row which has the max value. We can see more clearly what’s happening if we filter the data frame to only contain one letter:
> letterA = data %>% filter(letter == "A") %>% count(letter, number) > letterA Source: local data frame [10 x 3] Groups: letter letter number n 1 A 1 184 2 A 2 192 3 A 3 183 4 A 4 193 5 A 5 214 6 A 6 172 7 A 7 196 8 A 8 198 9 A 9 174 10 A 10 196
And now let’s apply the filter command while also printing out information about each row:
> letterA %>% filter(print(n), print(n == max(n)), n == max(n))  184 192 183 193 214 172 196 198 174 196  FALSE FALSE FALSE FALSE TRUE FALSE FALSE FALSE FALSE FALSE Source: local data frame [1 x 3] Groups: letter letter number n 1 A 5 214
If instead of getting the top number by letter we wanted to get the top letter by number we just need to reorder the field names in the count method:
> data %>% count(number, letter) %>% filter(n == max(n)) Source: local data frame [10 x 3] Groups: number number letter n 1 1 G 213 2 2 F 219 3 3 K 228 4 4 N 222 5 5 R 224 6 6 B 234 7 7 B 221 8 8 U 217 9 9 I 220 10 10 O 209
And if we want to see the letter that shows up least frequently we can change the call to ‘max’ to an equivalent one to ‘min':
> data %>% count(number, letter) %>% filter(n == min(n)) Source: local data frame [11 x 3] Groups: number number letter n 1 1 H 166 2 2 O 160 3 3 E 156 4 4 R 169 5 5 L 169 6 6 I 164 7 7 H 170 8 7 I 170 9 8 Q 166 10 9 W 162 11 10 J 168
Someone recently asked me what one thing would make any company’s Agile transformation and adoption more successful? Almost before the question left their lips, I shot back – “great reviews, company-wide great reviews!” The most mature Agile organizations I’ve seen have regularly scheduled company-wide review meetings. These reviews are light on presentation and heavy on demonstrating working successes. The other positive factor for these review ceremonies is that they have active participation by managers, leaders and C-Level executives. These organizations regard reviews as sacrosanct, too important or valuable to be interfered with.
During my Certified Scrum Master (CSM) training a few years back, our class was struggling to find an answer to the Magic Management Metric question. The Metric that enables managers to say, “Ah-ha! Now I get this whole touchy-feely, self-organized Agile mindset thing.” Our instructor was a little put off by the idea that we needed to prove our worth and the value Agile brings to the powers that be at our respective companies. His terse final answer was that “If a leader wants to know what the team is doing, come to the review!” After all, valuable working software delivered on a continuous basis trumps everything, doesn’t it?
Unfortunately, the reality is that the teams have become victims to our own self-crated Frankenstein’s monster. Most self-managed teams haven’t made it easy for leaders to attend even a handful of reviews. Each team plays by their own set of rules: some use two week iterations, some deliver daily but you can probably be sure that only 10%-20% of the reviews happen on the same day and even fewer happen at the same time.
This could be one of the driving factors towards the need for a more scaled multi-team view for agile delivery that is becoming more popular in the marketplace today. Process and program are seen as the glue that will bring various teams to communicate together. It’s not that companies don’t value individuals and interactions; they just value process and tools more, because the other way isn’t working too well.
The reality is that it is still desirable and possible to deliver customer value across self-organized lean teams, and many great companies are succeeding in doing so. One way is by adopting regularly held All-Company Agile celebratory review meetings to help foster the collaboration and communication team need to be more effective. It’s still about the interactions and delivering working software. For any enterprise looking for a better way to radiate information on a consistent and customer focused way, here are some ideas to help your teams and leaders engage and execute healthy “All-In” review ceremonies:
- Have ONE all-company review meeting; every team and every leader should be represented. This is sacrosanct, and it is the highest priority meeting on people’s calendars.
- Teams need to synchronize their review cycles to a regular meeting cadence. This can be helped by having teams align to their iteration schedules.
- Have a set schedule order for who is speaking, but don’t over prepare. Keep it concise, but allow enough time to show each team’s results.
- Each team gets an opportunity to demo their valuable customer working software during the review. Use collaborative online meeting options like GoToMeeting, if you have distributed teams.
- When it makes sense, show your customer using the new and improved software. DevJam’s David Hussman recently recommended using your mobile devices to record customers demoing the software as a great way to accelerate Product Driven Learning. You don’t need a documentary, just live, real video feedback.
- Reviews should be Agile method agnostic. You can regularly review the valuable accomplishments of SCRUM, XP and KANBAN teams at one time. It’s okay!
- Cheering, hooting, clapping, and congratulations are encouraged. It’s called a celebration for a reason. Woot, Woot!
- Feedback is encouraged, but even more important is having leaders engaged, present and observing what is and is not working and learning how to, as www.IllustratedAgile.com’s Leadership Engagement model shows, Encourage Monitor and Remove Big Impediments to support future team success.
- Facilitate the time for feedback collection and Q&A to help keep the meeting on track. Use other creative methods like breakouts, note cards, or a simple post-review on-line survey to collect and report feedback back to the product owners and teams.
- Course correcting is still reserved for the team-led retrospectives. Teams should regroup soon after the review, provide feedback and make tuning observations to improve future results. Then the actions should be shared, and provided to the appropriate levels across the org.
The interesting thing I’ve discovered from observing All-In reviews is that when everyone from the CEO down to the Summer Intern celebrates the wins of two weeks of effort, multiplied by many teams delivering substantial value to customers on an early and often basis, everyone wins. EVERYONE!
What types of actual results might you begin to see using ALL-IN reviews?
Team health becomes more transparent and the need for health-check driven metrics is reduced. This increases the time available for productivity gains and the overall delivery team morale. Quality is more apparent, defects are reduced and the feeling that I should check my Facebook or LinkedIN pages at work goes down. Leadership’s motivation to remove impediments and understand “the system” and the knowledge of what is truly going on goes-up. And finally, the ability to achieve shared company-wide goals and demonstrate the ways teams are impacting customers in a positive consistent way is recognized and encouraged to thrive.
Tom Peters says you should “Celebrate what you want to see more of.” Our highest priority should be to review team accomplishments, promoting even more success, more agility and more happy customers!
I just finished reading a great rant about being on time by Greg Savage. It got me thinking a bit. I’ve been involved with Scrum and other Agile methods since the mid-90′s and in that time, my perspective on time has changed considerably.
I used to be the guy who was always late. And it was a completely selfish behaviour. Meetings, outings, even weddings. I just couldn’t believe how “uptight” people were about time. But gradually, over a period of about 5 years as I became more and more aware of the underlying philosophy of Agile, my perspective, and more importantly my behaviour, changed: I started being on time. For everything. Even if it meant doubling my travel time buffer. Even if it meant sleeping 3 hours instead of 8 hours. Even if it meant missing a meal or a drink or a personal to-do item.
Time is the only resource that, once spent, we can never get back.
Scrum and most other Agile methods respect this implicitly in their time-boxed iterations and meetings. But people on Agile teams often need time to adapt and change their behaviour. In many ways, timeliness (starting and finishing meetings on time) is a critical component of the Scrum value of Respect.
Timeliness is also related to our understanding of planning. The Horizon of Predictability is short in most work environments. Maybe a week or two. If you dis-respect the tkmeboxes of the Agile process, you are jeopardizing your ability to effectively use the horizon of predictability. Even the Daily Scrum, normally time boxed to 15 minutes each day, can through abuse of time, cause long-term ramifications in product development planning.
But really, I like Greg Savage’s point better than all the practical stuff: being late is rude. Period.Try out our Virtual Scrum Coach with the Scrum Team Assessment tool - just $500 for a team to get targeted advice and great how-to informationPlease share!
It hadn’t been a very good race. In fact, it wasn’t an understatement to say it had been a disaster. To Peter Smith it was embarrassing just to show his face in the clubhouse afterward. He was at a complete loss to explain how it had happened. He felt like had just managed to snatch defeat from the jaws of victory.
He’d put together a decent crew. There were no rookies on the boat. Everyone knew their jobs and some had even sailed together before on other boats. Some even had more experience sailing than Peter did. It should have been a pretty decent team.
The boat was brand new. It was the latest club racer with all the bells and whistles. It was blazing fast on the water upwind and downwind. They had all the right equipment, the right sails, and every reason to win.
That’s why their performance was all the more frustrating for Peter. They’d sucked. There was no getting around it. He felt like he’d made all the right moves and still managed to fail. He’d reviewed it backwards and forwards and still had no idea what to do. It was definitely time for a beer.
Still licking his wounds Peter took a seat at the bar. Things were hopping and the whole place was abuzz with sailors recounting the day’s action. It happened that Pete had picked a spot next to one of the club’s old timers, Rex. Pete knew him only by reputation, but he was supposed to be one of the best racers in the club.
Rex was the gregarious type and soon introduced himself to Peter and asked how his race had gone. Beer now in hand, Peter proceeded to tell the story of the day’s humiliation.
“We went out on the water early and did some practicing before the race. We needed to get used to working with each other and get the kinks straightened out. We had no problem there. A few short tacks, a few gybes and we were ready to go.
So race time comes around and we get to the start and begin working for a good spot on the starting line. You know how it is, it’s a tough fleet, so there are lots of boats and they are all pretty intense. If you leave those guys an opening, they are going to take it and you can kiss a good start goodbye.
This is where we had the first hint that there might be an issue. As the maneuvers on the start line became more intense, the crew execution started to weaken. A boat would cut us off and we would have to spin to avoid them. As we would execute the spin, one of the trimmers would make a mistake and we would get stuck, stalled out behind the line.
Of course we would recover and try again, but is was the same story all over again. I’d have to execute another rapid maneuver and the trimmers would blow it again! It was intolerable. I began to yell, because we were never going to win a race performing like this. I don’t think the yelling helped much (in fact they seemed kind of annoyed), but what else was I supposed to do? I couldn’t exactly trim the sheets for them, could I?”
Peter saw Rex frown as he described this last bit, but he was starting to get some momentum in the story, so he powered on, “Anyway, when the starting gun when off, we weren’t in a good position and ended up starting in the second rank, sucking wind behind all the good guys who had managed to get off the line with good starts.
From there, things went tolerably well on the first beat to the windward mark. We did the best that we could with a bad start, but we still ended up toward the back of the fleet as we prepared to round the windward mark. Strategically, there wasn’t much we could do until we reached the mark, and we managed to execute well, with no major screw ups.
Of course that all changed when we reached the mark. That’s where everything fell apart. As we rounded the mark, the bowman wasn’t ready and we launched the spinnaker late as I was trying to gybe set and cover the competition. Nobody was ready! We ended up with the spinnaker wrapped around the forestay and the bowman was screaming at the trimmers to ease up on the sheets. There he was on the foredeck, flailing away trying to untangle the mess, as boats went by us on either side. Jesus was he slow! I hollered at him to hurry up, but I don’t think he was listening, because nothing changed. It was costing us the race.
Finally we got the spinnaker sorted out and we got ourselves back in the race. Only now we were at the very back of the fleet. That’s right, we were dead last. As if that weren’t bad enough, when we eventually got to the leeward mark, it was an even bigger disaster!”
Peter paused for a sip of his beer and continued, “I told the crew that we had to move faster to keep in the race, but it didn’t help. They just couldn’t execute. By the time we crossed the finish line, there was complete silence on the boat. No cheers from the crew. We all felt like we never wanted to do that again. I’m completely baffled. How could this have happened? Where can I get a good crew? I need a crew that can execute, not a bunch of whiners who shout at each other when things go wrong.
Look, I can’t change that it’s a race. We’re not in this to have a good time. We’re here to win a race. Why can’t anybody understand this? I need a little positive attitude here. I need people with a will to win! Where can I get some of that? We sucked!”
There was a long moment of silence. Rex was shaking his head and chuckling quietly to himself. He paused and looked at Peter with an assessing sort of gaze and said. “That’s a helluva story. I’ve seen it before. You want my advice?”
Peter looked down and swirled the beer at the bottom of his pint thoughtfully for a moment. Then he looked up and replied, “At this point, yes. I’ll do anything.”
“Buddy, what you are doing is pushing these guys, and what you really should be doing is pulling with them. You don’t succeed by pushing a team, you succeed by pulling along with them.” He said.
Peter frowned, “What the hell are you talking about?”
Rex paused to take another sip of his beer and continued. ”It’s like this, You can push the problems on the team. You can make it all their problem. In that situation, at the best, you are simply not helping, and at the worst, you are actually creating additional problems for the team.”
“Problems? What do you mean? I don’t give problems.” objected Peter.
“Hold on, let me explain: Let’s take your race today as an example. When you were maneuvering on the start line, what did you do to your trimmers?” Rex asked.
“I didn’t do anything to them. I spun the boat about and it was their job to trim the sails properly to execute the spin.”
“And did you tell them you were going to spin, or did you just slam the tiller over and wait for them to figure it out?” Rex tilted his head as he asked this last question.
“Well…I had to spin. I didn’t have any choice. Otherwise we would have hit another boat.” Peter said rather defensively.
“OK, so you had to spin, but you didn’t tell anyone what you were going to do, right?”
“OK, alright, yeah.”
“So, here’s the question: When you do that, turning without telling anyone, are you suddenly creating a problem for the trimmers or are you helping them?”
“Well OK, it’s not helping I guess.”
“That’s right. You’re creating a challenge or impediment for the trimmers to overcome – you’re pushing the problem on them. Not only do they have to trim the sails as fast as they can, but they also have to be mind readers – guessing at when you may spontaneously change direction without telling them.
Let’s look at this another way. What could you do to help them?”
Peter looked a bit sheepish and said, “I could call out the maneuver before it happens?”
“Right, if you did that you would be helping to make their jobs easier. You would be setting them up to succeed rather than setting them up to fail. You would be contributing to the successful execution of their work.”
“Yeah, I guess.” Peter said a little petulantly. “But I’m still not really sure what you mean by this ’pushing vs. pulling’ thing.”
“OK, well let’s talk about that mark rounding you did. What do you have to do to round a mark?”
“Hundreds of things!” Peter exclaimed. “Everyone has dozens of tasks that they each have to perform in a choreographed fashion in order for a mark rounding to be successful.”
“And what did you do to help them round the mark?”
“I did the steering, their jobs are their problem.”
“So again, how could you help?”
Peter gave it some thought and then said rather tentatively. ”Call out the maneuver?”
“Yes. What else could you do to help?” Said Rex.
“Well, I suppose I could slow down the turn in order to give them more time to make their adjustments?”
“Bingo!” exclaimed Rex. “That’s more like it. You have to be thinking of what you can do for the team to make their jobs easier. You need to think beyond your own role and be constantly asking yourself: How can I help the team? What can I do to help this team work like a well oiled machine? As long as you are thinking only of your job, you aren’t really part of the team. To be part of the team, you need to be pulling along with them to help them reach the goal.”
Peter nodded his head, “OK, I think I get that, but it’s kind of abstract don’t you think?”
“No, not really. I see it out on the race course all the time. You get these hyper competitive types rushing about without thinking about the team. They rush through mark roundings thinking only of themselves and winning the race and not about the crew. The poor crews are pulling as hard as they can, but they just aren’t in synch with the helmsman. They aren’t pulling together as a team.
It’s push vs. pull.” he finished.
Peter looked down pensively and was quiet for a minute. Then he called over the barkeep and bought Rex another beer. “Thanks. I appreciate the advice. I’m going to have to give that try.”
Filed under: Agile, Blogroll, leadership, pull, push Tagged: leadership, pull, push, sailing
Scrum is the most popular Agile methodology with Kanban a growing second choice. Learn about the core parts of each one as well as how they differ so that you can find the best fit for your team or organizational context. For example, Scrum is great when you want to shake up the status quo and transform the way you work. Kanban is great when small changes are a better fit for the environment. Learn how they work and how you can use them in your environment.Scrum and Kanban – Getting the Most from Each from Michael Sahota How to Choose Between Scrum and Kanban
Scrum will be more successful in environments where it’s requirements are met. If you have all six, Scrum is great. When you start loosing important bits of context it becomes more difficult.
Kanban is much more fault-tolerant and work in many more contexts.
- Beyond Roles in Scrum In this post we will explain how we can move...
Related posts brought to you by Yet Another Related Posts Plugin.
I am a frequent speaker at conferences. People ask me “why do you go through all of that hardship to prepare and present?” My answer is that every time I put myself out, I gain more insight from speaking to people that I know and meet. So, for me, it’s worth it. A couple of weeks […]
The post “The Wastes are Water”, and Other Advice from the Older Agile Fish. appeared first on BigVisible Solutions.
I was deeply moved by this letter. I’ve seen how Scrum and similar pull-based approaches not only improve productivity, but reduce stress and improve quality of life for people, and this is a powerful example. I asked the sender if I may share it with the world, and thankfully he agreed. Here it is:
Recently I picked up a version of your free online edition of “Scrum and XP from the Trenches, How we do Scrum” and I have to say it changed my personal and professional life.
I have been and software developer on interactive voice response systems for close to 20 years now.
A few months ago I was speaking with a colleague and mentor of mine about his efforts to become a certified Scrum master. Up until this point I had never really been exposed to Agile and Scrum in detail and only knew some of the jargon. My colleague suggested that I research and learn more about the Agile philosophy and in particular Scrum. Since I have been suffering from a poor work life balance almost my whole career I decided to pay it some attention.
I read your paper on a Saturday night and decided that Sunday that I would implement Scrum start on Monday morning. So I quickly pulled together a spread sheet with what I had that night and formalized the excel sheet that was our product backlog. That Monday I held my normal morning meeting with my development team and the rest is history.
The short of it is that my team is finishing up its 3rd sprint next week and we all love it. A lot of the stress that was keeping me up at night has completely gone away. I feel in complete control when I come to the end of my work day. In the past two months I have even hung out with my family on Saturdays and Sundays. I have begun to add more of a balance back to my life.
I really wanted to thank you for writing this paper and putting it out in the world for free. The tips that your paper offered have literally saved my marriage and probably my life.
Thank you again for you effort.
Here’s a roundup of features that have either recently rolled out or are coming soon, including: Changing start and finish dates Calendar view updates Default board security settings Two way connections Personal profiles My LeanKit for iOS Customizable card icon Recent Enhancements Changing Start and Finish Dates New quick edit capabilities for start and finish […]
Um ihren Produktentstehungsprozess planbar zu machen, setzen viele Unternehmen eine Form von Meilensteinplanung ein. Im Detail gibt es hier viele Unterschiede, aber das Prinzip ist immer das gleiche: Die Meilensteine sind Punkte entlang einer zeitlichen Achse, zu denen das Entwicklungsprojekt intern evaluiert wird. Die Zeiträume zwischen den Meilensteinen bilden häufig die Entwicklungsphasen nach dem V-Modell ab. In solchen Fällen folgt auf eine Machbarkeitsstudie die Konzeptionsphase, gefolgt von Design-, Verifikations- und Validationsphasen. Um einen Meilenstein zu “passieren”, wird anhand von festgelegten Dokumenten und Reviews überprüft, ob die vorangehende Phase erfolgreich abgeschlossen wurde.
Zugleich entscheiden sich immer mehr produktentwickelnde Unternehmen (längst nicht mehr nur in der Softwareentwicklung) für den Einsatz agiler Rahmenwerke wie Scrum. Hier kommt dann sehr schnell die Frage auf, ob und wie Scrum mit einer Planung in Meilensteinen “vereinbar” sei oder zumindest “kompatibel” gemacht werden könne. Aus meiner Erfahrung beruht allein schon diese Wortwahl auf der falschen Vorstellung, dass Scrum und Meilensteine zwei Prozessvarianten seien. Wenn das so wäre, müsste man sich für eines von beidem entscheiden – oder eben einen Kompromiss finden, der ein wenig von dem einen und ein wenig von dem anderen realisiert (was auch immer das dann konkret bedeutet).
Scrum ist eine Methode. Scrum sagt, dass Produkte iterativ (in regelmäßig wiederkehrenden Sprints) und inkrementell (Feature für Feature) entwickelt werden, damit die Organisation nicht erst zum Ende des Projektes, sondern kontinuierlich lieferfähig ist. Meilensteinpläne schreiben vor, welche Dokumentation wann im Laufe eines Projektes erzeugt und freigegeben werden muss. Scrum ist darauf ausgerichtet, die Entwicklung am Bedarf des Marktes auszurichten. Meilensteine sind hingegen interne Revisionsmechanismen, um Projekte auf der Spur zu halten.
In meinem aktuellen Projekt sind wir zum Start folgendermaßen vorgegangen:
- Zunächst sind wir die Bausteine der Meilensteinplanung einzeln durchgegangen und haben uns jeweils gefragt, ob diese für eine erfolgreiche Produktlieferung zwingend erforderlich sind.
- Jene Bausteine, die für eine erfolgreiche Produktlieferung zwingend erforderlich sind (z.B. Risikoanalyse, Produktvalidierung, Test der elektromagnetischen Verträglichkeit – EMV), kommen in unsere Definition of Done. Darin klären wir, auf welcher Ebene (Story, Sprint, Release) wir sie einhalten können und wen wir dafür wann heranziehen müssen (z.B. QA beim Schreiben von Testfällen in der Sprintplanung).
- Das hat in der Regel zur Konsequenz, dass die erforderlichen Bausteine deutlich früher geliefert werden, als sie nach der Planung in Meilensteinen gefordert wären.
- Die Bausteine, die für eine erfolgreiche Produktlieferung nicht zwingend erforderlich sind (z.B. Erstellung Lasten- und Pflichtenheft), lassen wir außen vor und betrachten sie nicht weiter.
Zusammenfassend: Es wäre naiv, Meilensteinpläne komplett zu ignorieren. Manche der dort vorgeschriebenen Deliverables sind sehr wohl für eine erfolgreiche Produktlieferung wesentlich. Genauso naiv aber wäre es, die Vorschriften 1:1 umzusetzen, nur weil es der Plan so besagt. Vor allem bietet Scrum die Chance, die starre Abarbeitung von Meilensteinen dadurch überflüssig zu machen, indem die kritischen Projektaspekte schon zu Beginn angegangen werden, so dass der Zweck der Meilensteinplanung – die Projektabsicherung – ohnehin erfüllt wird.
My next upcoming SAFe SPC Certifications are as follows:
Dec 9-12, 2014, Boulder, Colorado (with Alex Yakyma)
January 27-30, 2014, Boulder, Colorado (with Alex Yakyma)
March 2-5, Vienna, Austria (with Michael Stump)
March 10-13, Boulder, CO (with Alex Yakyma)
Also, I’ll be delivering an SPC certification in Sydney, Australia, the week of June 22, but that one isn’t yet open for registration. Please ping Garren Watkins (email@example.com) if you’d like to pre-register.
I look forward to meeting some of you in person at these upcoming events.
In addition, in response to increased market demand, we’ve also increased our capacity for 2015, with classes to occur about weekly world-wide. The first half of 2015 has been scheduled now, as you can see at Scaled Agile Academy.
Come join the league of over 1,700 SPCs who are making a huge impact in the world with SAFe!