I once worked for a manager who thought everyone should bow down and kiss his feet. Okay, I’m not sure if he actually thought that, but that’s how it felt to me. He regularly canceled his one-on-ones with me. He interrupted me when I spoke at meetings. He tried to tell the people in my group what to do. (I put a stop to that, pretty darn quick.)
He undermined my self-confidence and everything I tried to accomplish in my organization.
When I realized what was going on, I gathered my managers. At the time, I was a Director of Many Things. I said, “Our VP is very busy. I think he has too many things on his plate. Here is what I would like to do. If he interrupts your work with a request, politely acknowledge him, and say, “Johanna will put that in our queue. She is managing our project portfolio.” If he interrupts you in a meeting, feel free to manage him the same way you manage me.” That got a laugh. “I am working with him on some customer issues, and I hope to resolve them soon.”
My managers and project managers kept on track with their work. We finished our deliverables, which was key to our success as an organization.
My relationship with my manager however, deteriorated even further. In three months, he canceled every single one-on-one. He was rude to me in every public meeting. I started looking for a new job.
I found a new job, and left my two week notice on his desk. He ran down the hall, swept into my office and slammed the door. He slammed my notice on my desk and yelled at me, “I don’t accept this! You can’t do this to me. You can’t leave. You’re the only director here accomplishing anything.”
I said, “Are you ready to have a one-on-one now?”
He said, “No. I’m busy. I’m too busy for a one-on-one.”
I said, “I’m leaving. We have nothing to discuss. You can put your head in the sand and try to not accept my resignation. Or, we can make my last two weeks here useful. What would you like?”
“You’re not done with me, Rothman!”
He stalked out of my office, and slammed the door on his way out. I got up and opened the door. I was never so happy to leave a job in my entire life.
Some managers don’t realize that they are not their title. Some managers don’t realize that the value they bring is the plus: the management, plus their relationship with their peers, the people they manage, the systems and environment they enable/create. This guy had created an environment of distrust.
That’s what this month’s management myth is all about: believing that I am More Valuable Than Other People.
If you are a manager, you do provide a valuable service: servant leadership. Make sure you do so.
There are lots of little things that can boost your experience within Axosoft. Today we’ll talk about this little triangle.
You’ll see this right triangle with all its 45-45 degree glory in the black column header and you will also see it when you create subitems. There are three different settings for this little guy and we’ll briefly breakdown each one.
If the triangle points to the right, then you will hide all your subitems. This one is the easiest to figure out. You can do this locally for each parent item or you can set it for all the items in view by changing the triangle in the main header.
Points to the Lower Right:
The next one gets a little tricky. If the triangle points to the lower right (and it will have this tiny hole in the center of it), then you’re telling Axosoft to only show the subitems that match your filter. If I have my name selected under users for example, this setting is a great way of only seeing subitems assigned to you.
And of course, this one will reveal all subitems. It was really that second one that you should try to use more.
There you have it! You now have the knowledge to streamline your viewing and filtering even further. Be on the lookout for more tips to come and check out some other useful shortcuts here.
Als ich vor ein paar Wochen die Informationen über meinen neuen Consulting-Auftrag bekam, war ich gespannt und neugierig zugleich. Erstmals ging es für mich um ein Projekt, das im ERP-System (Enterprise Resource Planning) von SAP angesiedelt war.
Neben einer Weiterentwicklung der hausinternen ABAP-Eigenentwicklung (Advanced Business Application Programming) sollten auch diverse Anpassungen in einem SAP-Standardmodul umgesetzt werden. Letzteres beinhaltet zu großen Anteilen das sogenannte „SAP Customizing“. In diesem Prozess wird das SAP Standardmodul durch einen SAP Berater mit Hilfe von Konfigurationen auf die im Unternehmen eingesetzten Geschäftsprozesse angepasst. Dabei werden die Berater von Entwicklern unterstützt, um etwaige Sonderfunktionalitäten im Standardmodul abzubilden, die nicht mit Hilfe des Customizings realisiert werden können.
Die Vorgehensweise des SAP Customizings ist in vielen Unternehmen typisch klassisch nach einer Wasserfallmethodik ausgerichtet. In einem ersten Schritt wird basierend auf dem Anforderungskatalog ein Konzept entwickelt, indem die Datenstrukturen und deren Verknüpfungen über Masken und Dialoge festgelegt werden. Anschließend werden in der Umsetzungsphase diese Datenstrukturen erstellt und das Standardmodul so angepasst, dass es den Geschäftsprozessen des Unternehmens entspricht.
Die ersten Sprints
Die ersten agilen Iterationen gestalteten sich als äußerst schwierig. Das fehlende Konzept verunsicherte Einzelne der SAP Berater, da sie stets das Gefühl hatten, das SAP Standardmodul im „Blindflug“ zu customizen. Auch die vielen Veränderungen basierend auf dem Feedback des Kunden führten zu Unmut, da Datenstrukturen wiederholt angepasst werden mussten. Den Satz „Das wäre uns mit einem Konzept nicht passiert“ hörte ich unzählige Male. Die Frage, die sich mir stets stellte, war, ob es in früheren Projekten nie zu Change Requests gekommen war? Die Antwort war, dass diese sehr wohl Bestandteil der Projekte waren, aber nicht mit der Häufigkeit wie in agilen Projekten auftraten. So weit so gut, wir beschlossen, die agile Methode einfach durchzuziehen.
Der Kunde war bereits nach den ersten Sprints hochzufrieden mit den Lieferungen des Projektteams. Noch nie zuvor war es ihm möglich gewesen, bereits nach dem ersten Sprint ein vorführbares Ergebnis zu sehen. Es konnte doch tatsächlich ein gesamter Geschäftsprozess durchgespielt werden; auch wenn dieser großteils noch manuell zu bewerkstelligen war und erst in den Folgesprints automatisiert wurde.
Die SAP Berater, angesprochen auf die Erfolge mit der Kundenzufriedenheit, räumten nach ein paar Sprints ein, dass sie immer noch Schwierigkeiten mit der neuen Methode hätten und dass sie „ihr“ Konzept vermissten. Sie sahen sich aber auch mit der Tatsache konfrontiert, dass sie die Einzigen waren, die ihr Konzept vermissten. Für den Kunden, der in früheren Projekten ursprünglich das Konzept vor der Umsetzung absegnete, war das Fehlen eines Konzeptes nicht weiter tragisch. Zumeist hatte er das Konzept ohnehin nicht vollständig verstanden und mit der neuen Methoden konnte er nach ein paar Wochen nicht nur einen Stapel Papier, sondern schon Teile seiner Endlösung sehen.
Der Erfolg des Projektes zeigt, dass auch ERP-basierte Projekte, wie jenes mit SAP, agil entwickelt werden können, ganz gleich, ob es um Programmierung oder Customizing handelt. Es geht in jedem Fall um die Schaffung neuer Funktionalität, um die Entwicklung eines neuen „Produktes“. Wie immer in solchen Prozessen hilft die iterative Vorgehensweise, den Kunden schneller zu beliefern und insgesamt zufriedener zu machen.
- In Scrum we trust?
- 3. Deutschsprachige Scrum Gathering
- Scrum & das Team – Rückblick auf den ScrumDay in München
The more I explore how IT organizations work, the more I see how strikingly diverse they are. They are as unique as human beings. Each organization has its unique process, unique culture and unique service or product that they deliver. On the surface, it might seem that businesses can be broken down into categories, e.g. a small or a large, a production or a service company, and there’s indeed a certain similarity. The big “but” comes into play when an organization wants to achieve some outstanding goal, e.g. increase sales by 300%, or cut down the time to production by 50%. There’s no such thing as similarity then. Small things in which companies differ then gain the last-drop power for a breakthrough to happen. The uniqueness lies in custom mixes of organizational culture and production process. Unique goals require unique ways to achieve them. I will use software development industry as an example to illustrate one striking phenomenon that holds they key, the Holy Grail to getting things done efficiently in unique organizational contexts.Solve a Unique Problem by Copy-Pasting a Solution? No way.
At various phases of their lifecycles, organizations have to address their unique challenges. What do stakeholders usually do first as they encounter a problem? One disturbing commonplace trend that I’ve noticed is to replace addressing the root of a problem with a trendy buzzword model or management technique, and rely on it thinking: “Once we implement this super thing in our company, all our problems will be resolved.” Or, if the Super A..buzzword technique is implemented, and brings no results, stakeholders keep staying in the limited stalls of prescribed buzzwords, and then that’s what they think: “Hmm, the Super A.. thing is not working. How about we try a Super K… thing?” I’ve written about that in my previous articles on agile, Kanban and Big Data, as I looked at their origin, and on how they play out in the long run. It could all be very well if this approach with sticking, or switching, to one coined technique or another helped in 100% of cases. That’s not true, however. It seems that most organizations have slid from the ruthless clarity of a simple “why?” to juggling boxes filled with loud labels for what some time worked for someone. Thinking is the hardest job, and with the amount of cognitive loads that we, Homo Sapiens, experience these days, organizational stakeholders are tempted to use shortcuts and grab the leash of what a mega-guru has said should be done. *Totally forgetting that the mega guru probably used this technique or a tip for an organization that is completely different from yours*.
Which consequences does this habit have on a larger scale? Trying to fit a unique context of an organizational challenge to a limited set of Super A.. or Super K… techniques is an attempt in futility. If there’s some fat on the belly, that is, if this organization can afford paying for such abstract things as “measuring agility” (???), then the stakeholders would hire a consultant to translate the language of how things work in their organization to a lingo of a Super A.. technique, and/or will send their employees to be certified in this new religion, and/or introduce some ridiculous measurements that would serve it. Such reality shows are ubiquitous, and the following lame syllogism crowns them: “We are going Super A.. now, so we need a tool to call ourselves truly Super A…” or ” Hmmm… Super A.. does not work for us. The sales are not higher, and we do not have faster turnaround times, and Super A… is not helping us find out if what we are doing is actually right or wrong for our organization if we want to hit this target. Hmm. They now say a lot about the Super K.. technique. Yes! Let’s try it. Let’s switch to Super K.. and, of course, we want to be truly Super K.. so we need a tool for that!”
No comments.The Health Check: 5 Why’s and 6 W’s
The quickest health check is to ask the 5 Why’s. Why are we doing this? If the name of the Super A.. will still linger in the answer to your very last 5th “why”, you can probably throw the super A.. to the trash bin. Your organization needs to deal with real things. Not with the labels in a toy store. The other health check is the 6 W questions technique (What? Why? Where? Who? When? Which?) applied to what you have in plan for projects and processes. As a side note, I don’t care from which buzz management Super XYZ lingo the 6 W’s and 5 Why’s originate (and, yes, I do know of Six Sigma). These are the simplest bulls..it detectors to verify the actual worth of an approach to management.
It breaks my heart to read articles and blogs on software development written exactly with the Super Whatever shallow mindset. I can’t stand looking at how limited thinking prevents people from grasping the uniqueness of their challenges and addressing them effectively. I can’t stand looking at how the loud name of “methodology” is haphazardly glued to the how-to techniques and practices that worked only for certain organizations. And, I’ve explored the reasons for that thing happening in one of my previous articles. The education that IT professionals receive is too narrow. It doesn’t allow them to look beyond how-to’s too much, as they are not even trained to look beyond the how-to’s. The how-to approach works for coding, or for dealing with mechanisms, but it doesn’t work for organization/product/project management. I’m humbly hoping that my articles help to provide broader and deeper perspective, a perspective that someone might need to fix things gone wrong in their organizations.
Back to my intolerance to the evil reign of how-to’s and to the habit of their copy-pasting. This habit is even more dangerous than smoking or drinking, because with these everyone knows they are bad habits, while with the how-to’s abuse, people keep thinking that if everyone else does it, then that’s OK.Pragmatism is Dead, Long Live Pragmatism!
It’s time to regain justice and call things their true names. Let’s retrieve one precious treasure from the chest of eternal wisdom and blow the dust off of it. The treasure that lies there abandoned has this written on its plate:
A methodology is a school of thought, and a method is a way of doing something.
In other words, practice is the only criterion for truth. On the meta-level, this reasoning is backed up by the philosophy of pragmatism. However, there can be a shallow pragmatism and a smart pragmatism. A shallow pragmatism, briefly, is a short-sighted plan and course of actions, while smart pragmatism is something that I’ve written about in the article Visualization: Why the Fusion of Arts and Tech Matters.
The smart pragmatism, for software development, occurs when the blind sages touching various parts of an elephant recover their sight and realize that all of its parts function as a whole. Often organizations held their internal mini-wars, especially as they grow, between marketing teams and production teams, as they divide the spheres of responsibility between many decision-making groups, and when those parts have to merge, it feels like flying through the rough air. The head does not know what legs and arms are doing, something of that nature.
I want to make null and void any methodologies except “use your guts”. There’s no such thing as a success of a one part. Success comes as a whole, and for that success to happen, unfortunately (or fortunately), there’s no other way as to think outside-the-box, sometimes even forcefully blocking the trendy how-to’s. One can read tons of books, or follow gurus, or “best practices”, but these activities are secondary as compared to independent thinking. Sometimes, it’s a surprising and a pleasant side-effect to discover that you have arrived to the same conclusion as some renowned guru did, but by yourself, in your practical context. And this is a lot more precious and effective than copy-pasting a technique with no deeper understanding. That’s why, if you have no guts — grow them. If you have guts, but you’re too tired, get some rest and restore your ability to think independently and clearly.No Need for Ninjas, but Let’s Call This Thing Somehow
The use-your-guts pragmatic methodology does require a method (a way of doing). I’ve checked on most of the methods used in software development. Some of them have common sense in-mixed with limiting prescribed practices (see my article Stuck with Kanban? Consider Multiban). As you might have guessed, I have invented a method that is based on Kanban, but differentiates from it in the core “way of doing “. And, although I’m quite skeptical about using new names for what appears to be clear, I still have a name for that method: Multiban. This word is a Japanese-English mixture, and means something along the lines of many boards, many views and many perspectives. This name will stick in the memory, as it implies connection with Kanban method, with one important update. While Kanban uses cards as static signs for work items only, Multiban uses cards as dynamic signs for any abstract or concrete entity. Multiban is a visual management method (see and use your guts) that has no prescribed practices. All Multiban wants are custom visual representations, multiple 2D views of crossed rows and columns, that support whichever perspective to power your thinking. Why I deemed Kanban a good method to build on further? It’s because of the “visualize” part. That’s about the only thing that is unquestionable about the Kanban method: visualization. Nothing else supports the pragmatic, use-your-guts thinking better than visualizing. Indeed, when things are brought from heads to paper (or to screens), that’s a huge aide. Pragmatic stakeholders need more ways to look at what happens with their projects and processes, than with static Kanban cards that signify work items.
Now, as I’ve identified this method, for free-thinkers who want unlimited help and unlimited freedom with their unique ways of thinking, let’s see which digital tools might support this. Most of the Kanban tools are limiting. They lack versatile visualizations. Here’s a write-up about one such pretty decent Kanban tool that, however, fails to deliver many views and many perspectives. Quite predictable, I found out that so far only Targetprocess 3, our visual management software, supports the unlimited thinking and free-from-the-leash no-nonsense work — and the Multiban method — as it brings to the table unlimited 2D views for any dataset. No strings attached, the tool also allows to exercise agile, Scrum, Kanban and other SUPER ABC things. But the most important part about Targetprocess 3 is that it supports your own unique way of thinking and decision-making, be it on micro-level with bug fixing, or work items management, or on macro-level with managing portfolios of projects, or with roadmaps, in ERP or wherever.
I’m probably trying to squeeze too many things in one article. Each of the aspects I’ve touched upon deserves an article by itself. I’m certain that what this world lacks most is insightful out-of-the-box thinking. People are stuck in prescribed patterns on many levels in their lives, their work in software development, or organization/product/project management being one of them. I want to tackle this, and that’s why I will persistently champion the smart pragmatism and the Multiban method in my writings.
If you want to learn more about how Multiban stands out as a method and as a technique for visual management, check the related articles.
I published another Pragmatic Manager this week, Time for a Decision. It’s about program management decisions, and collaborating across the organization.
Do you receive my Pragmatic Manager emails? If you think you are on my list, but are not receiving my emails, let me know. Some of you long-time subscribers are not receiving my emails because of your hosts. I am working on that. Some of you don’t subscribe yet. You can subscribe. I write something valuable at least once a month. I post the newsletter on my site when I get around to it, later.
I hope you enjoy this newsletter. If you don’t already subscribe, I hope you decide to sign up.
The agile principle of inspect-and-adapt applies to agile managers as well.
@lyssaadkins & @mspayd
- How Adobe Got Rid of Traditional Performance Reviews | by Bob Sutton http://t.co/6WGBJp6tTE
- How Rally Does … Executive Planning and Steering | Rally Software Community http://t.co/J659wDqxml
- Rightshifting Recruitment | Think Different http://t.co/pfOjNH9uobJan 09, 2014
- Introducing Open Salaries at Buffer: Our Transparent Formula and All Individual Salaries http://t.co/v0qgvI8lT4
- Role of Managers in Agile Retrospectives | by Ben Linders http://t.co/BbHmcrfdhl
I don’t claim these articles to be the best on this subject, but I have enjoyed reading them and they have made my knowledge grow. I recommend you to have a look if you are interested in the subject. Happy reading!
Follow me on twitter @hlarsson for more links on a daily basis. You may also subscribe to weekly newsletter of my links. Thanks to writers of these articles and Kirill Klimov for collecting the agile quotes: http://agilequote.info/. Please follow @agilequote for more quotes.
Lynn Winterboer - (@agilelynn) With a proven background in a variety of data projects and agile practices, Lynn Winterboer teaches and coaches DW/BI teams on how to effectively apply agile principles and practices to their work. For almost 20 years, Lynn has served in numerous roles within the analytics, business intelligence and data warehousing space. She has worked in numerous industries, including insurance, banking, retail, energy, high-tech manufacturing and channels, telecommunications, education, internet security, web marketing, government and healthcare. Lynn very well understands the unique set of challenges faced by DW/BI teams who want to benefit from the incremental style of Agile development; Lynn leverages her experience and training to help deliver practical solutions for her clients and students.
I have noticed a recent increase in the number of recruiters contacting me for Product Owner roles, many of them looking for someone to work with a data-focused team (my area of expertise). I just chatted with a recruiter looking for an experienced product owner (PO) to work with a healthcare company’s analytics team in the Denver Tech Center area. (Know anyone?) We both bemoaned the fact that there aren’t many experienced POs available in the market, much less any who have a good background in working with data warehousing/business intelligence/analytics. I can imagine other teams struggle to find product owners with the right amount of experience in their industry or business function.
If you are looking to hire product owners for your analytics team, and can’t find the perfect person on the market, I have an idea for you.
Step 1: Find someone who has the right experience as an analytics business analyst and WANTS to work in an Agile framework:Focus Why Eliciting business requirements for BI/DW/Analytics projects. One must know how to ask the right questions and capture the right information related to DATA projects (which can be different than requirements for workflow, web or mobile projects!) Business process analysis: How the inputs, actions, and outputs of each step in a process add to (or inhibit) the value the organization gets from the process. Product Ownership is all about understanding, articulating, and prioritizing the VALUE each piece of work brings to the organization. Solid experience working with data One needs some good, healthy scar tissue from wrangling with data in order to understand the challenges faced by the delivery team members and work collaboratively with them REALLY good relationship skills across all business functions, from accounting to sales Product Owners for BI teams often need to support multiple functions in the business. Therefore, a PO has to facilitate and negotiate priorities across these various functions. (See “BI Product Owners Love an Agile PMO!” for more on this) Natural tendency toward, and desire to learn more about, agile practices: Focuses on team success over personal glory, loves to learn and grow regularly, comfortable with change, already knows agile is a MUST HAVE in future career choices! Agile is not for everyone. There are places where traditionalists would be happier than on an Agile team. Agile is simple in concept and difficult in execution. One has to have a deep passion and drive to live the agile values and principles or it just won’t work.
STEP 2: Train, mentor and coach this person to work within an Agile framework:Topic Why What is “Agile”? One needs to understand the background, tenets, and various approaches of the Agile movement in order to have a strong foundation to stand on. Throughout a product owner’s career, it is very helpful when in doubt to go back and review the Agile values and principles, and figure out how to align with them. How do DW/BI/Analytics projects work within an agile framework? The data world has some additional challenges to working within an Agile framework that other IT groups don’t. There are also ways in which an agile approach is a better fit for data teams. It’s important to understand these differences so the PO can be a healthy participant in the delivery process. How does a Product Owner build a roadmap based on prioritized projects and capabilities? This is where a PO’s experience in cross-functional relationships and business process analysis comes in handy. The Product Owner seeks out and takes multiple viewpoints into account, assesses organizational value for each opportunity, and decides the order in which the delivery team should focus on each project/capability. The agile world has lots of good practices available for POs to use in prioritizing and building a roadmap. How does an agile team initiate a project? The PO is responsible for creating a project vision and motivating involved folks to quickly deliver organizational value. It’s a big job! Fortunately, there are agile practices that make this a community event where everyone leaves with a common understanding of, and excitement for, a new project. This allows the delivery team to be much more autonomous in figuring out the best way to deliver the desired product – which leads to better code as well! How does the Product Owner write, prioritize and groom user stories? The Product Owner has a big responsibility – to make sure the team is building the RIGHT THING (while the team focused on building the THING RIGHT). Without this leadership, a team can quickly iterate in the wrong direction and fail to deliver value – even with perfect code. Most of the user story classes and examples available to Product Owners today are based on web or mobile projects, and it can be difficult for a new PO to “translate” that guidance into something useful for a data-focused team. Training and mentoring on user stories for analytics teams shortens the learning curve and reduces false starts. How does the PO know when to accept a story as “done”? A key method for making sure the user stories are clear for the team is to include detailed acceptance criteria for each story – possibly even to the point of articulating the tests that would need to pass to “prove” the story is complete. This takes a lot of work, and is critical for the PO to reduce wasted team effort (building the wrong thing due to misunderstanding) and creating faster value for the organization.
In my experience, it’s more difficult to teach somebody about the nuances of the data world (this often takes years of hard-won experience to really understand), than it is to teach them about the Agile approach. The main reason is that Agile is a journey and the community is supportive of “newbies” with the right attitude who want to continuously learn and grow. One of the key tenets of ALL agile frameworks is a regular and frequent “inspect and adapt” process (often called retrospection) that allows participants to learn from their mistakes and do it differently next time. It’s a wonderful situation for someone learning something new!
We recently released an Assembla Hubot script to the public allowing you to interact with Assembla from your organization’s preferred chat apps such as Slack, Skype, XMPP, and so many more. If you're not familiar with Hubot, he's a highly customizable robot that sits in your company's chat room and provides easy access to various tools, services, comic relief, and time wasters.
For months, we have been using this script internally to deploy code and interact with Assembla from our own chat rooms. We hope your team loves it as much as we have.What can the Assembla/Hubot script do?
Fetch information on Assembla users, tickets, and projects
Merge/ignore/display merge requests
View and invoke SSH tool actions
An automated merge-and-deploy (via SSH tool) action
Deploying from the chat speeds up our workflow and allows the team to easily see changes being shipped to production. We simply tell Hubot what merge request we are ready to merge to master and deploy to production and it takes care of the rest. Learn more about how Assembla’s SSH tool and Hubot streamlined our deploy workflow.
For a full list of commands, visit: https://www.npmjs.org/package/hubot-assemblaHow to get started
Follow the instructions on npmjs.org: https://www.npmjs.org/package/hubot-assembla
In order to configure Hubot, you will need to create an Assembla API key by visiting https://www.assembla.com/user/edit/manage_clients (leave website and redirect URLs blank)
If you have any problems or questions with setting up Hubot, please let us known in the comments or by contacting email@example.com
If you are interested in adding to our script, you can fork our code and we will review pull request for submitted additions
Presenting at conferences is a great experience where you get to consolidate your knowledge and connect with other people passionate about the same things. But speaking in front of your peers can be a scary prospect for developers and they often underestimate the value to others of what they know. For instance in our teams, we have lots of experience with XP, Continuous Delivering, UX and JS testing frameworks. Does that mean we're all experts? Not necessarily but we can share practitioner experiences and that's a valuable to people who're only just getting started with new approaches.
Back in January, I started a lunchtime meeting called "Conference Club" for anyone in our team who wanted to learn more about the steps they need to take to present at industry conferences. Five months later, I'm pleased to see that several of the people who came along have submitted sessions to calls for participation and been accepted as speakers.
- Alex and Benji presented on "Scaling Continuous Delivery" at Pipeline conference in London
- Vikki presented a comparisonof front-end acceptance testing frameworks at JsDay in Verona
- Arber will be presenting on "Extreme Product Development" at Agile North
- Mike will be presenting on "Zombie Personas" at Agile2014.
We only had a few meetings of Conference Club but it was enough to explore people's worries and share some practical tips on how to get over them.Basic Steps
- TOPIC: Identify topics you are interested in and know something about
- BIO: Update your profile on LinkedIn / GitHub / blog / Twitter to reflect your interest/experience
- WHERE: Find meetups / conferences that might people go along to discuss that topic which have open space or CFP (call for participation)
- DATES: When do you need to submit a proposal by, these can be upto 6 months before the conference date
- FORMAT: consider what format is best fit for you and conference (workshop, talk, experience report, etc)
- PREPARE: design material slides or exercise to lead session participants through subject of interest.
- PROPOSE: put forward your idea to organisers
- PRACTICE: do a run thru of session with small group to work out any glitches
One basic thing that speakers need to do is practice so we have a fortnightly lightning talks forum that can be used to build confidence speaking to an audience. Unconference events are also great places to explore a topic as you figure out what you want to present to a wider audience.Homework Assignments
1) Write a bio for someone else at the meeting using Scott Berkun's tips on how to write a good bio
2) Prepare an answer to one of the following questions from Noel Rappin's blog
3) Write an abstract for a new session you'd like to propose for a user group or conference.Useful Blogs
- Conference speaking HOW-TO
- Confessions of a Semi-Amateur Speaker
- Debricking yourself as a speaker
- Kent Beck on how to write a conference abstract
- Chad Fowler on how to give a keynote
- Podcast on slowing down pace
- Presentation Skills Considered Harmful
- Dealing with stage fright
- Presentation Zen summary
- Breathing for voice projection
- How to project your voice
- Triangle Method for eye contact
I also recommend following Callback Women to pick up upcoming call for participation.
Build the Right Thing, Build it Right, Build EnoughUnder Scrum, the objective is to produce a potentially shippable product every sprint. Scrum is an incremental framework, which means you achieve your overall goal incrementally. Each sprint, even each backlog item, produces an additional slice of the product. This slice is integrated with all previous slices into a whole. That potentially shippable whole is called the "Increment."
Everything that goes into the Increment has to be "Done" and the increment as whole has to be "Done." If it's not done, you can't ship it. So what does it mean for something to be done? That's what the Definition of Done is for.
The Definition of Done is an agreement between all the members of the Scrum Team: what does it mean in your context for something to be done? So regardless of who you ask on whether something is done, you should always get the same answer.
To come up with a Definition of Done, I have found it useful to look at Doneness in the context of three questions:
- Have we built the right thing? (External Quality)
- Have we built it right? (Internal Quality)
- Have we built enough value to justify releasing? (Fitness for Use)
Imagine you are buying a car. You ask the car dealer for a red car with 2 doors, leather seats, automatic transmission, air conditioning, heated seats, and probably some other essential features. Your dealer can't deliver that car right away, so you come to an agreement to order that car, and 30 days later, that car is sitting in dealer's lot, waiting for you to pick it up. Did you get the car you ordered?
You check the car against the order: color, transmission, number of doors, presence of air conditioning and heated seats. If it matches the order, you say, "yes, this is the car I ordered." The car conforms to what you ordered, so you say thank you and take the car home.
Customer Intent, or building the right thing, is usually reflected in some kind of acceptance test. When this test passes, the customer is happy. For a car, we know in advance what a car is and what features it can have, so defining the car by a list of acceptance tests (aka - order form) is easy to do, and most customers can order a car at that level alone.
In Scrum, customer intent is identified during the conversations between the Development Team and the Product Owner or other domain experts. (This is often called Estimation, Backlog Refinement, or Release Planning.) The Product Backlog item is enriched with the "confirmation" - a description to confirm that the solution or implementation satisfies the objectives set for it. Scrum does not define how to do this. In a software development context, some widely used practices include:
- a simple workflow, "How To Demo," to show that the feature is working correctly.
- a set of conditions and expected results ("Given <a known state> when <some action occurs> then <expect some result>"), or even
- a collection of examples that pass or fail. For example, to convert integers to Roman Numerals, you might have a table that starts like this:
0 -> #badInputError
1 -> i
2 -> ii
3 -> iii
But how do you know that the car is legal to operate in your jurisdiction? How do you know that the air conditioning will produce enough cold air so that you can drive comfortably in the heat of summer (without being so cold as to cause respiratory illness!) ? How do you even know it was built according to the designs of the engineers who designed it? How do you know that your new car satisfies the larger requirements to be road legal in your jurisdiction? How do you know that the car will outlive the warrantee?
So many questions! Can you verify this as a customer or even as a (non-technical) Product Owner?
In general you are dependent on the manufacturer to do their job right. In Scrum, it's harder, because you are building a product for the first time. While the Development Team is responsible for achieving "Done" for each feature they build, the whole Scrum Team is responsible for the quality of the product.
How does the Development Team ensure internal quality? At this level, the Definition of Done looks like a checklist. Here is a typical Definition of Done for a moderately mature Scrum team that develops Software for an iPhone/iPad environment:
- Unit tests written
- Code checked in
- Code review completed
- Improvements from review implemented
- All new unit tests green
- All existing unit tests stay green
- Build available for download in TestFlight
- Acceptance tests verified by Development Team
- Done confirmed by Product Owner
This example includes automated testing. Why? If something was Done in the last sprint, shouldn't it stay Done in this sprint? If not, how can you call it done?
Personally, I have had the best results applying the Definition of Done to each backlog item, not to the increment as a whole.Unfinished workWhen deciding whether a backlog item is done or not, the Product Owner should ask the Team, "Can we release it?" If the team says, "Nope, we can't release it" (or any of its more subtle variations), then the work is not Done, and the appropriate response is "Why not?" The answer is un-Done work. It goes into the product backlog -- because it has to be finished before you can release -- and should be a subject of the next retrospective: How can we have less un-Done work at the end of the next sprint?Completion / Fitness for UseUnder what conditions do you actually ship the increment? This is a judgement call. The Definition of Done is not a Definition of Complete or Definition of Releasable for the product as a whole. Assuming there is no un-Done work, the Product Owner may decide to release at any time. The product should be releasable by the end of each Sprint, and possibly more often than that. Very mature teams in very dynamic environments often strive to achieve continuous deployment.
Under Scrum, you achieve releasability incrementally by implementing one feature at a time. Eventually you will have implemented enough features that the Product Owner decides that implementing more features will not add more value to the product and/or the cost of releasing is justified by the value to be earned by the release. In this case, the Product Owner asks for a release. If the Increment is truly done, the Team will respond, "Sure, no problem!"Create a Sample Definition of Done - (Non-Software)What if you are not doing software? How does this apply? Just ask your team:
- How do we ensure we have built the right thing? (External Quality)
- How do we ensure we built it right? (Internal Quality)
- Does it conform to the appropriate CI/CD?
- Does it contain customer CI/CD?
- Has it been spell checked?
- Has it been proof-read?
- Has it been fact-checked?
- Does it have enough pictures and graphs?
- Have we confirmed that the content represents value to the customer?
- Does the content address a key goal of the study?
So almost by definition, your Definition of Done will only be partially done in the greater scheme of things. Does Done include User Acceptance Testing? Does it include Customer Acceptance Testing? Does it include validation from the marketplace that the feature is necessary and desirable? Is it feasible to check these things on a feature by feature basis?
In general, you should strive to make you Definition of Done more extensive as your project moves forward. As Done becomes "done-er" your quality is rising, and with it, your productivity.
If there is no alternative to handing your product off to a downstream process, then understanding what it means to be ready for that process can be very helpful. When I developed an iPad app, I had to be sure that Apple would accept it according to their terms and conditions. So my team looked at the contract, and we figured out Apple's Definition of Ready, and made sure that our product conformed. As a consequence, we are able to get our apps on to the app store without too much hassle.
If you have a downstream process, one question to raise is how can you integrate those stakeholders better, so that you are more in synch on what Done means and what is really done. If you have stakeholders or customers who also have to accept the product, how can you get them more involved in your process so that Customer Acceptance Testing happens during the project, not at the end, and any testing at the end becomes more a rubber stamp formality than source of risk and surprises?
If you are building for the market, you don't really know if you have built the right thing until you have gotten that confirmation from the market. How would you integrate market validation into your process?
Summary: The Three Faces of Done in ScrumScrum says simply, we have to agree what "Done" means. The definition of Done should help you answer the first two of these three questions effectively:
- Have we built the right thing?
- Have we built it right?
- Have we built enough value to justify releasing?
There is a bonus question, especially when developing software: How do we ensure that what gets Done in this Sprint, stays Done in future Sprints?
If your team can answer all these questions well, you are on your way to high and predictable team performance, delivery dates and product quality!
Credits: This perspective on Done and the terminology used was inspired the Lean Software Development series by Mary & Tom Poppendieck.
[Update: 11:00 I have tweaked this article a bit for spelling, grammar, readability and completeness. I need a Definition of Done for my blog articles ;-) ]
It’ about time to give the Product Owner a chance to fight back. With the help of Heiko Weltin I created a list as a base for the revenge. I hope you’ll like it:
- Create your product backlog without any prioritization. In the end you need all of the features before you can bring the product to the market.
- Only create the headline of your user stories and don’t add any additional content, even if the team asks. You can’t prepare everything for the team.
- Only use two types of priorities: “Urgent” and “Can be done later”. Anything else would be a waste of time.
- Always promise release dates and scope to your customer without talking to your development team upfront. You are a skilled estimator.
- Always add one task to a user story that keeps the team from finishing it. The Definition Of Ready (DOR) is for wimps.
- Insist in long running sprints of at least four weeks. If the team has more time, more features can be done.
- Only prepare as many stories as needed to finalize half of the sprint. The rest of the time it is the task of the developers alone to clarify the rest of the stories.
- Only meet once a week with the team and keep this meeting as short as possible. You don’t want to hang out with those sissies.
- Always answer your phone during any team meeting. Don’t leave the room as the team shouldn’t be able to continue the discussion without you.
- Never attend the daily scrum. Instead, talk to single developers afterwards. This makes it easier to build pressure on them.
What do you think? Do you have some additions to this list? Feel free to add them in the comments.
It’s about time to nag the product owner, isn’t it. Fortunately, there are plenty ways to do this. To help you in your quest to do so I created a list of 10 proofed ways to drive your Product Owner crazy:
- Five minutes before the Sprint Review is the right time to tell your Product Owner that your team wasn’t able to finish anything. It is even more fun, if this was a planned release. Transparency is for milquetoasts.
- Don’t invite the Product Owner to any Scrum meeting. He is a chicken and you are the pigs, right.
- Ignore the Sprint backlog and work on the features you like the most. Who cares about the Product Owner’s vision?
- Assign all tasks that were created during your retrospective to your Product Owner. He is the root of all evil and responsible for all the problems in the project.
- Don’t attend the Sprint Review. You already know how your product looks like.
- Never show the real product in the Sprint Review. Instead, prepare a nice and shiny power point presentation.
- Never talk to the Product Owner if you have questions about a feature. Instead, implement it based on your favorite assumptions.
- If it is difficult to establish a stable communication to your Product Owner, define someone in your team to become the so called Product Owner proxy.
- Always break your release date promises. Everyone loves surprises.
- Question everything that is in the product backlog and try to start lengthy discussions about as many features as possible. At least, that’s what your mother told you.
Try this out and post your experiences in the comments. If you have additional ideas, feel free to add them, too.
The new year has just started and it’s time for the next steps to rile your team mates. So let’s have a look at one of the activities in Scrum that can be easily sabotaged: the retrospective. Here are 10 proofed ways to wreck any retrospective:
- Keep the retrospective as short as possible. No need to invest too much time in this meaningless gathering.
- Only focus on negative events and ignore any positive things. This is the only valid path to improvement.
- Handle a retrospective as any other meeting. Sit around a table and just talk.
- Ignore the complexity of the system around you. There is always a cause and effect.
- Always use crappy material such as cheap post-its that easily fall from the walls or old pens that hardly write.
- Forgo a facilitator for your retrospectives. It is only a burden and will slow the whole “meeting” down.
- Don’t use any agenda and deliberately ignore the retrospective’s phase model.
- Directly start with defining what has to be changed in the next sprint. Everybody already knows what has to be done.
- Never check if the defined tasks of the last retrospectives were done or even had the desired effect.
- Never bring food to your retrospectives. Hungry participants will do anything to finish a retrospective as fast as possible.
What else could you do? I’m looking forward to your suggestions in the comments.