Experience with Sinatra, and some thinking, has caused us to look at a shift in approach. Martin Fowler was probably right.
Early in this project, Martin wrote to me, asking “why dynamic” and offering his bliki software for my use. My answers were that to get my hands dirty, I really wanted to do it myself, and that I chose dynamic solely on the principle of late binding. I’ve somewhat come to my senses.
I am a very old person, which I hope is not in any way noticeable, despite my desire that you all keep off my lawn. I came to realize that while I hope I’ll be writing and drawing stupid pictures for a long time, I will probably not be wanting to fiddle with configuring Ruby/Sinatra/Kramdown/etc on my web site for very long at all. In fact, I already don’t want to do that. I also don’t want to maintain the WordPress stuff that is there now, especially since my webmistress (not as interesting as it sounds) is leaving the area.
Therefore, I decided that I wanted a static site. Some software now, to generate it, but push come to shove you can push new articles up with FTP or similar tools, so it will be relatively maintainable ad infinitum.
(I freely grant that I could be entirely wrong about all this. Nonetheless, static is hopefully here to stay.)
So, a bit of looking and we’ve settled on Jekyll as a basis for the site. In second place, Middleman, which I rejected on the basis of its (non-) documentation. In third place, just code it up. Code it up is running strongly and could catch the leaders.Starting on ronjeffries.com
Happens I own ronjeffries.com. (No, don’t bother to buy up all the other ronjeffries.etc, and sell them to me at a profit. Dot com will do me just fine.)
So the current plan is to build up ronjeffries.com incrementally. We’ll deploy it as soon as my host can get it set up. He’s a bit overwhelmed with personal matters just now but I want to stick with him.
The site wants to integrate XProgramming, new material, maybe even my tumblr. So it needs to be able to support something not unlike the current organization. All the articles (at least the ones I decide to keep), and a bit of organization, done with categories in WP.However …
Jekyll doesn’t quite want to do all that, at least not at first glance. Let’s revisit the requirements.
My existing site has the notion of general articles and three special kinds: Kate, Beyond, and Classic. The front page shows the most recent Beyond, the most recent Kate, a random Classic, and then, after that row, the five or six most recent other articles. I think I’ve mentioned in previous articles that those groupings may not be quite right, but the basic idea applies.
Jekyll, it seems, is “blog aware”. What that means in practice seems to be that much of its capability revolves around having a list of posts named 2014-10-11-foobar, and laying them out in a typical blog style. Next/prev, dated indexes, and the like. All very well and good but not quite what I’m about.
I write a bunch of articles about generally Agile topics. Those ought to be some kind of category, perhaps the Beyond heading, perhaps not. There might be threads. I write series of coding things like the recent ones with Codea. These generally don’t go anywhere, they just display how I’m approaching developing something over the period where I play with things. (I should probably say at the beginning of each of those that it will not have a nice live happy ever after ending, because when I get bored with that tool or topic, I’ll stop.)
I write Kate Oneal stories. I write other themed things.
Each of these needs an index page, and some of the lists are long and courtesy suggests the index should be paged.
And I have a writing requirement, or at least writing desire, which is to put each article and its associated pictures in its own folder. This makes writing easier (currently using Sublime Text and Marked) because I can view what it looks like as I go, and can push it up without worrying about name overlap in an images folder.
I plan to have the article “slug” (which I guess means web-compatible name) be the name of the folder, and in a great concession, I am prepared to name all the articles index.markdown, each in its own folder. I’d rather give them a meaningful name but at least right now I’m not seeing quite how to make that happen in Jekyll.
And I really don’t want to call them all 2014-10-11-whatever, though perhaps I need to get over it.What’s there and what’s apparently not
It’s early days with Jekyll, we just talked about it via email a tiny bit last week, read some stuff, and I tried some things yesterday. Here’s what I think I have learned.
Jekyll will scan your whole input folder structure and process files you tell it to, and will process any file that starts with some YAML. It digs down through nested folders at least as well as I need it to.
But inside the standard _posts folder, it will only process files with the date prefix format, as far as I can tell. That is, a file containing YAML but not named by the date standard, gets ignored entirely. It’s not even copied over raw. In other folders, Jekyll processes the text files and copies others such as images. So inside posts, I’d be stuck with the dated names. I really don’t want to go there.
In other folders than _posts, it processes most everything, so I can put all my articles under, say “Articles” and they’ll all get run through kramdown and rendered to html. They can have categories, and other goodies in the YAML, so maybe a flat structure would be enough.
And there are “collections” in Jekyll. They are red-flagged with markers saying they might change. What seems to maybe happen (based on a limited experiment) is that you can name a collection in your config, then have a folder of that name, and everything inside it goes into the collection. Then you can process that collection in your templates and includes.Where are we?
We’re in very early days in Jekyll, just finding our way. Today will be our first day pairing with it. Should we just use categories or the like to sort out the Kates from the Beyonds? Should we use collections?
We’re not sure. I’ll report more when I know more. Meanwhile, if you know stuff I should know about Jekyll, please drop me an email. Thanks!
An der Generation Y wird gerade wieder diskutiert, was die Wahlfreiheit mit uns macht. Einerseits wollen wir sie nicht mehr missen und anderseits gehen wir unter ihr in die Knie. Hier ein Beispiel:
Es gab mal eine Studie, bei der den Probanden auf der Straße ein Eis geschenkt wurde.
- 1. Set up
Die Probanden haben 3 Sorten Eis zur Auswahl: Vanille, Schokolade und Erdbeer. Jeder bekommt genau eine Kugel Eis. Anschließend werden sie befragt, wie zufrieden sie mit ihrer Wahl sind. Ergebnis: Sie sind durch die Bank glücklich, ein Eis geschenkt bekommen zu haben und froh über die Wahl, die sie getroffen haben.
- 2. Set up
Die Probanden haben 10 Sorten Eis zur Auswahl: Stracciatella, Limone und was man sich noch so denken kann. Jeder bekommt wieder genau eine Kugel Eis. Die Antworten bei der anschließenden Zufriedenheitsbefragung fallen diesmal allerdings ganz anders aus. Die Mehrheit der Befragten ist weit entfernt von Zufriedenheit. Die Tatsache, dass sie gerade etwas geschenkt bekommen haben, schwindet aus der Wahrnehmung. Kennzeichnend für die Stimmung der Leute ist allein das Gefühl, die falsche Wahl getroffen zu haben: Eine der anderen Sorten wäre bestimmt leckerer gewesen.
Es kommt darauf an
Zunächst einmal hängt das davon ab, welcher Typ ich bin.
Persönlichkeitsprofil-Modelle wie das MBTI, oder die Lehre von Motivationsprofilen, besagen, dass es Menschen gibt, die durch permanente Wahlmöglichkeiten motiviert sind und sich wohler fühlen je mehr Optionen zur Auswahl stehen. Und andere Typen halten es in undefinierten Situationen schwer aus und sind bestrebt, die Türen schnell wieder zu schließen, einen Haken dran zu machen. Lieber irgendeine Entscheidung als keine.
Und dann hängt es von meiner Kompetenz ab, mit Wahlfreiheit umzugehen.
Schauen wir uns an, welche Antworten das Scrum-Universum auf dieses Dilemma hat.
In Scrum hat alles seine Zeit. Türen öffnen hat seine Zeit und Türen schließen hat seine Zeit.
Beim Review, bei der Retrospektive und beim Backlog-Grooming mache ich den Raum auf für neue Ideen und Möglichkeiten. Bei den Sprint Plannings schließe ich die Tür wieder, indem ich mich entscheide, was ich in den nächsten zwei Wochen machen will. Und im Sprint drehe ich den Schlüssel vom Sicherheitsschloss zweimal rum. Jetzt gehe ich mit meiner Entscheidung und verwandle sie in eine Erfahrung. Am Ende der zwei Wochen weiß ich, ob das eine gute Entscheidung war.
Was kann die Generation Y daraus lernen?
Für Antworten brauche ich Erfahrungen*. Ohne Entscheidung kann ich keine Erfahrung machen. Und ohne Erfahrung gibt es keine Kurskorrektur.
Ich schließe mit einer kleinen Geschichte.
Ein Bauer kommt zum weisen König und fragt ihn, ob er ihm erklären kann, was Freiheit ist. Der König fragt den Bauern: “Kannst Du ein Bein heben?”
“Ja”, sagt der Bauer.
“Gut, welches Bein willst Du heben?”
Der Bauer überlegt kurz und sagt dann: “Das linke.”
“Gut”, sagt der König, “dann hebe Dein linkes Bein.”
Der Bauer hebt darauf sein linkes Bein.
“Jetzt heb Dein rechtes Bein”, sagt der König daraufhin zum Bauern.
Der Bauer schaut ihn verdutzt an und sagt: “Aber das kann ich nicht.”
“Siehst Du”, sagt der König, “jetzt weißt Du, was Wahlfreiheit ist.”
In diesem Sinne, viel Spaß beim Entscheiden.
*”Und Dich hat man wieder mal ausgelacht, weil Du für Antworten Erfahrungen brauchst” – aus dem Lied //www.youtube.com/watch?v=z73vzMfWgMs
Erfahrungen” von Felix Meyer
He began the talk with his experience coming out of college with an engineering degree. He found the math and science classes did little to prepare him for the real world, the people part of the equation, or the “all important last 99%” of being successful. It’s the soft skills that are hard, the people and relationship skills but that’s not what is the focus of education.
He then went on to talk about the Agile Manifesto and how that is the key to successful project management. From here, he shared some other pieces of wisdom
- Politics is life, relish it. If you don’t like politics, you probably shouldn’t be managing projects
- While intelligence (IQ) is important, having good emotional intelligence (EQ) is more important
- Whoever tries the most stuff wins. Again, sounds like the idea popular in agile circles about failing fast.
- To be effective, you need to “suck down” and help the people on your team. He didn’t use the phrase “servant leadership” but that’s what it sounded like to me.
- There’s no excuse for a poorly run meeting. Take the time to prepare so that it is effective. We can’t get rid of meetings.
I’m always pleased to see bright people explaining and summarizing SAFe better than I can. In a recent post, Eric Willeke, a leader in the kanban community, describes how SAFe handles WIP limits at the portfolio level (after all, if you don’t limit the really big WIP there, the rest of the system may be in deep trouble, no matter what else you do). He also points out the connection between Portfolio WIP management and Lean Agile Budgeting, which is a critical, though subtle, connection that helps achieve flow.
here is the post: http://ericwilleke.com/posts/safe-portfolio-limits/
and here is an excerpt/teaser:
by Eric Willeke.
Portfolio Distribution: SAFe significantly simplifies the decisionmaking around the above concerns through the recommended budgeting approach, which explicit allocates both budget, delegated financial authority, and scope determination to the release trains as the default approach. This leads to a significantly reduced portion of the overall spend being managed as explicit items in the portfolio flow, Instead, the majority of the work can flow “horizontally” at the train level without incurring the administrative and governance overhead associated with the larger items flowing through the portfolio backlog. The portfolio flow is intended to be used only for those items that cut across trains and are of sufficient size that they need explicit financial governance. Reference. SAFe additionally provides an optional value-stream level coordination layer to manage coordination of those cross-cutting items that demand additional coordination due to the various dependencies that remain after making the organizational structure trade-off decisions without adding the additional financial governance overhead.
I once worked in a team with an amazing developer, let’s call him Henry (not his real name). Henry refused to play the Tech Lead, preferring to stay as hands-on with code as much as possible. When the team had a technical problem, they would first go to Henry. He always offered a well-balanced opinion on technical decisions which meant the team almost always agreed with his proposals. Even business people recognised his technical aptitude. When he asked for time to work on important technical tasks, he always got it.
Although Henry was just a “Developer”, he lead the team in a number of ways.Taken from https://www.flickr.com/photos/growwear/4695020138 under the Creative Commons licence You don’t need to be a “Lead”
My experience with Henry showed me how you do not need a title with “Lead” to demonstrate leadership. Conversely, having a title with “Lead” doesn’t suddenly bestow someone with leadership skills.
A developer who cleans up some messy code without being asked demonstrates initiative. The tester who brings the developer and Product Manager to the same understanding demonstrates facilitation skills and these play a part of leading people. In this situation, it means:
Thinking and doing something for the benefit of the team without being told to do so.
There are, of course, many other attributes to being a leader, but that is a separate post.A Lead without leadership
You have probably worked with one of these people. A leader who tells people what to do, berates their team members for stepping slightly out of their role, even when the result is beneficial for everyone. They often have the need to supervise the smallest task and always want a say in every decision. These people are nothing other than micromanagers and demonstrate no leadership skills whatsoever.Great leaders encourage leadership
Unlike micromanagers, a real Lead focuses on creating an environment that allows everyone to demonstrate leadership. In chaotic situations, this may require more directive action with the goal of moving the team beyond a period of chaos into a safer environment. In a safer environment, the Lead encourages team members to do what they think is right. The Lead takes on a more guiding role and allows everyone to demonstrate leadership skills.Action is not the same as a title
Henry the developer demonstrated that people can take on responsibilities without officially playing a certain role. He also reminded me that titles, certifications and labels do not automatically guarantee competence. If you truly want to lead, you can.
If you liked this article exploring leadership, you will be interested in “Talking with Tech Leads,” a book that shares real life experiences from over 35 Tech Leads around the world. Now available on Leanpub.
The featured image is shared from Flickr under the Creative Commons licence.
On Tuesday October 14th the Amsterdam Middleware Meetup experimented with Dropwizard. The idea was to find out what this technology is about, where it could be useful and what the alternatives are. So below I’ll give you an overview of Dropwizard and compare it to Spring Boot.
The Dropwizard website claims:
Dropwizard pulls together stable, mature libraries from the Java ecosystem into a simple, light-weight package that lets you focus on getting things done.
I’ll discuss each of these claims below.
Stable and mature
Dropwizard uses Jetty, Jersey, Jackson and Metrics as its most important frameworks, but also a host of other stuff like Guava, Liquibase and Joda Time. The latest Dropwizard release is version 0.7.1, released on June 20th 2014. It depends on these versions of some core libraries:
Jetty - 9.2.3.v20140905 - May 2014
Jackson - 2.4.1 - June 2014
Jersey - 2.11 - July 2014
The table shows that stable != out-of-date which is fine of course. The versions of core libraries used are recent though. I guess ‘stable’ means libraries with a long history.
The components of a Dropwizard application are shown below (taken from the tutorial
- Application (HelloWorldApplication.java): the applications main method, responsible for startup.
- Configuration (HelloWorldConfiguration.java) sets configuration for an environment, this is where you may set hostnames for systems the application depends on or set usernames.
- Data object (Saying.java).
- Resource (HelloWordResource.java): service implementation entry point
- Health Check (TemplateHealthCheck.java): runtime tests that show if the application still works.
We did some experiments trying to answer the question whether Dropwizard applications are light weight. The table below summarizes some of the sizes of deployments and tools.
Tomcat size 14 mb
Tomcat lib folder size 7 MB
Jetty size 14,6 MB
Jetty in Dropwizard jar: 5,4 MB
Dropwizard tutorial example 10 mb
Dropwizard extended example 20 MB
Dropwizard Hibernate classes in package: 5 MB
A Tomcat or Jetty installation takes about 14 MB, but if you count only the lib folder the size goes down to about 7 MB. The Jetty folder in Dropwizard however is only 5.5 MB. Apparently Dropwizard managed to strip away some code you don’t really need (or is packaged somewhere else, we didn’t look into that).
Building the tutorial results in a 10 MB jar, so if you would run a webapp in its own Tomcat container, switching to Dropwizard saves quite a bit. On the other hand, deployment size isn’t all that important if we’re still talking < 50 MB.
Compared to your default Weblogic install (513 MB, Weblogic-only on OSX) however, savings are humongous (but this is also true when you compare Weblogic to Tomcat or Jetty).
We tried to run the build for the tutorial application (dropwizard-example in the dropwizard project on Github). This works fine and takes about 8 seconds using mocks for external connections. One option to explore would be to run tests against a deployed application. What we’re used to is that deploying an application for test takes lots of time and resources, but starting a Dropwizard app is quite cheap. Therefore it would be possible to run an integration test of services at the end of a build. This would be quite hard to do with e.g. Weblogic or Websphere.
Spring boot is interesting, as well as the discussion around the differences between Spring boot and Dropwizard. See https://groups.google.com/forum/#!topic/dropwizard-user/vH1h2PgC8bU
The official Spring boot website says: Spring Boot makes it easy to create stand-alone, production-grade Spring based Applications that can you can "just run". We take an opinionated view of the Spring platform and third-party libraries so you can get started with minimum fuss. Most Spring Boot applications need very little Spring configuration.
It’s good to see a platform change according to new insights, but still, I remember Rod Johnson saying some ten years ago that J2EE was bloated and complex and Spring was the answer. Now it seems we need Spring boot to make Spring simple? Or is it just that we don’t need application servers anymore to divide resources among processes?
Dropwizard and Docker
Finally we experimented with running Dropwizard in a Docker container. This can be done with limited effort because Dropwizard applications have such a small number of dependencies. Thomas Kruitbosch will report on this later.
About a third of the way through Mastering Data Modeling the authors describe common data modelling mistakes and one in particular resonated with me – ‘Thin LDS, Lost Users‘.
LDS stands for ‘Logical Data Structure’ which is a diagram depicting what kinds of data some person or group wants to remember. In other words, a tool to help derive the conceptual model for our domain.
They describe the problem that a thin model can cause as follows:
[...] within 30 minutes [of the modelling session] the users were lost…we determined that the model was too thin. That is, many entities had just identifying descriptors.
While this is syntactically okay, when we revisited those entities asking, What else is memorable here? the users had lots to say.
When there was flesh on the bones, the uncertainty abated and the session took a positive course.
I found myself making the same mistake a couple of weeks ago during a graph modelling session. I tend to spend the majority of the time focused on the relationships between the bits of data and treat the meta data or attributes almost as an after thought.
The nice thing about the graph model is that it encourages an iterative approach so I was quickly able to bring the model to life and the domain experts back onside.
We can see a simple example of adding flesh to a model with a subset of the movies graph.
We might start out with the model on the right hand side which just describes the structure of the graph but doesn’t give us very much information about the entities.
I tend to sketch out the structure of all the data before adding any attributes but I think some people find it easier to follow if you add at least some flesh before moving on to the next part of the model.
In our next iteration of the movie graph we can add attributes to the actor and movie:
We can then go on to evolve the model further but the lesson for me is value the attributes more, it’s not all about the structure.
Karl Bredemeyer hat in seinem Artikel “Scrum in der Medizintechnik” die allgemeinen Vorteile agiler Methoden für die Entwicklung medizintechnischer Produkte beschrieben. Durch einen iterativen und inkrementellen Ansatz sind Verifikation und Validierung durch die gesamte Entwicklung hindurch möglich. In diesem und den nächsten beiden Beiträgen zeigen wir anhand von konkreten Beispielen aus unseren Projekten, wie das geht.
Anders als bei reinen Softwarelösungen sind bei medizintechnischen Produkten in der Regel verschiedene Komponenten – Mechanik, Eletronik, Software – miteinander zu integrieren, um ein Produktinkrement zu erreichen. Nehmen wir ein Beispiel:
Bei einem Gerät zur Laborautomatisierung soll ein Schließmechanismus für Röhrchen gebaut werden – dies ist unser Produkinkrement. Die Mechanik wird sich um Greifarme und Achsen kümmern müssen, die Elektronik um Motorsteuerung und Fahrmethode, und die Software um die Koordination der Arbeitsabläufe. Die Integration aller Komponenten zu einem funktionierenden Mechanismus mit wirtschaftlichem Wert kann nur dann gelingen, wenn zu jedem Zeitpunkt spezifiziert ist, wie sich das Gesamtsystem zu verhalten hat. Ausgangslage dafür sind in Scrum so genannte Epics. Sie postulieren, welche Funktionalität ein Benutzer des Systems braucht, und welchen Nutzen er davon hat.
Beispiel: Als Medizinisch Technische Assistentin (MTA) brauche ich einen automatischen Schließmechanismus für Röhrchen, damit ich die Laborproben nicht mehr von Hand verschließen muss.
In der Regel gibt es mehr als eine Epic pro Produkt. Neben dem Schließmechanismus könnten beispielsweise Öffnungsmechanismus, Transportmodul, Aliquotierfunktion sowie Ein- und Aussortierer dazukommen. Die Auflistung aller Epics in einer nach wirtschaftlichem Wert priorisierten Liste bildet das Product Backlog.
Im nächsten Schritt werden die Epics in Anforderungen, Akzeptanzkriterien und -tests sowie in Rahmenbedingungen analysiert. Das kann dann für die Epic aus unserem Beispiel folgendermaßen aussehen:
Anforderungen: Die Röhrchen sollen durch automatisches Aufdrücken einer Kappe verschlossen werden.
Akzeptanzkriterium:Der MTA muss keine zugelassenen Röhrchen mehr von Hand verschließen.
Akzeptanztest:600 Röhrchen mit zugelassenen Maßen werden innerhalb von 30 Minuten auslaufdicht verschlossen.
- Muss mit Röhrchen von 13-16 mm Durchmesser und 65-100 Millimeter Höhe funktionieren.
- Verschluss muss dicht sein.
- Kappe muss aus Polyethylen sein.
- Farbe der Kappe muss blau sein.
Ist eine Epic so heruntergebrochen, lässt sich bestimmen, welche Komponenten welchen Entwicklungsstand haben müssen, und welche Tests auf Komponenten- und Systemeben laufen müssen, um die Epic laut Akzeptanzkriterium zu erfüllen. Im hier genanten Beispiel werden Software, Elektronik und Mechanik so zusammenspielen müssen, dass Röhrchen zuverlässig versiegelt werden können. Ist dieses funktionale Zusammenspiel erreicht, ist das Produktinkrement erbracht.
Die Entwicklung orientiert sich an der sequenziellen Fertigstellung von Epics, die nach ihrer Priorität fertig gestellt werden. Somit ist zu jedem Zeitpunkt ein Produkt vorhanden, das potenziell (natürlich begrenzt auf die aktuell vorhandenen Funktionen) verwendbar ist. Weitere, nicht notwendige Funktionen (z.B. Zentrifugierung) können dann mit einem späteren Release ausgeliefert werden.
Im nächsten Beitrag erfahren Sie, wie Sie ein Entwicklungsteam zusammenstellen, das in der Lage ist, Produktinkremente zu liefern.
- Drei Argumente für Scrum in der Hardware
- Scrum History | Ken´s Talk über Qualität
- Wer hat Angst vorm ersten Wurf?
I am very pleased to announce that my “Agile Adoption Roadmap” Blog has just reached 100,000 hits. This is a great milestone and it makes me happy that there are so many professionals curious about Agile including many Agile enthusiasts, advocates, champions, coaches who are visiting and even commenting on my articles. It highlights that the many articles have value. If you want to receive its value, consider following this blog at: http://cmforagile.blogspot.com/.
To add to the statistics, I have folks from 45 different countries that have visited my site. The top 10 countries include: United States, United Kingdom, India, Russia, Germany, Canada, France, Australia, Ukraine, and China. Other countries that have significantly visited my site are: Sweden, Poland, Spain, Finland, South Africa, Iran, Norway, Iraq, Romania, Brazil, Argentina, Belarus, Malaysia, Portugal, Netherlands, Switzerland, and Italy.
The Agile Adoption Roadmap blog provides the reader with a range of topics related to adopting Agile within their teams and organizations. The content has a special emphasis on “being Agile” and bringing the Agile mindset to your work. I have written and posted 56 articles to date (although this one technically counts as the 57th). What are some of the top articles that Agile, IT, and Business Professionals have found of value? The top articles include:
- Who makes the best Scrum Master
- Agile Animal Farm – Pigs, Chickens, and more
- Agile Value Capture Metrics – Are you building value?
- Right-sizing Documentation in an Agile World
- Agile Definition of Done Starter Kit
- Agile – Its more disciplined than you think
- Gamification of your Agile Journey
- Agile Culture – Are you stepping up?
- The Role of Middle Management in an Agile World
- Are you Ready for your Agile Journey?
- Agile Executive Playbook
- Robust Agile Requirements – Its about the Discussion
- Is it finally time to “Be Agile”?
- Personas – Do you really know your Users?
- User Story Writing Starter Kit
- Agile Lagging to Leading Metric Path
Luis Gonçalves has posted a list of 100 Top Agile Blogs, ranked by Alexa ranking. I’m gratified to make the list, where I’m in some pretty good company.
Luis Goncalves has put together a list called the 100 Top Agile Blogs:
If you don't know Luis, he lives and breathes driving adoption of Agile practices.
Luis is also an Agile Coach, Co-Author, Speaker, and Blogger. He is also the co-founder of a MeetUp group called High Performing Teams, and he is a certified Scrum Master and Product Owner.
Here is a preview of the list of top 100 Agile Blogs:
For the rest of the list, check out 100 Top Agile Blogs.
Lists like these are a great way to discover blogs you may not be aware of.
While there will be a bunch of blogs you already know, chances are, with that many at a glance, there will be at least a few new ones you can add to your reading list.
Why is this?
Are the fringe areas more likely to be customer-focused?
For traditional enterprises, digital areas tend to be on the fringes and digital areas also tend to be significantly more customer-focused.
Peter Lee pointed out another possible explanation. In large enterprises, all the policies and processes will be designed for the core areas, not for the fringes. The fringe areas are already used to having to do their own thing, so Agile being different is not as big of a deal.
If this characterisation is true, does this suggest a path for successful Agile adoption?
- Start and establish on the fringes and ignore any focus on the core
- Get official endorsement (to protect gains)
- Core teams gradually adopt OR the fringes become dominant and slowly push out the old core
As promised, we’ve added to what you can do when you sign in to Tracker with Google. Now, you don’t have to integrate Tracker with your Google Apps domain to be able to attach your Google Drive files to stories, after you next sign in via Google.
When you sign in via Google, we’ll have to ask you to grant access to Tracker one more time.
We require the metadata permission in order to show you (and only you) a list of your recent Google Drive files, when you click the Google icon in expanded stories.
Note: Tracker cannot access content of files on your Google Drive. Also, even after they are added, no-one can open any of your Google files, unless you’ve shared those files with them in Drive.
If you choose not to accept the needed permissions, and not use your Google Drive files in Tracker, then just sign in with your Tracker password.
We’d love to hear your feedback on what else you might like to be able to do with Tracker and Google together. So please let us know your ideas and questions via email (and follow us on Twitter for the latest Tracker news).
I’ll need to elaborate on this at some point, to share what I’ve experienced across lots of businesses large and small, as well as some of the biggest businesses on the planet, as they transform themselves for the digital economy.
Meanwhile, here is an interesting read on CIO Straight Talk magazine.
In their words, "CIO Straight Talk is a series of "straight talking" articles from senior IT executives and leading companies and government and nonprofit organizations."
This first edition is focused on learning, failing and learning in the Second Machine Age, and features two non-practitioner experts on current topics:
“Andrew McAfee, co-author of the New York Times bestseller The Second Machine Age, cofounder of MIT’s Initiative on the Digital Economy and Principal Research Scientist at MIT Sloan School of Management, talks about ‘The CIO’s role in the enterprise of the future.’ Says McAfee: ‘The overall trend is that companies of all stripes will need, proportionately, many fewer people in IT. Those who remain will be very highly valued, very highly skilled, very important… Enterprises are going to need someone to help them navigate the second machine age… I think that if the CIO plays her cards right, this can absolutely be her role in the enterprise.’”
Michelle Gallen, the CEO of Shhmooze, a social networking start-up, talks about failure, not to be confused Failure Lite – ‘I failed. How nice. I learned so much’ – often hailed breezily by management experts as something everyone should experience and every company should encourage. Real failure, according to this serial entrepreneur, isn’t pretty. Says Gallen: ‘I don’t think you learn without failing… In the start-up world, innovation is the ability to take an idea and turn it into an invoice. Lots of larger business organizations also rely on cash flow to keep them alive, and therefore innovation has to be monetized. If you’re Apple or Microsoft, you’ve got a war chest, and you can actually allow failure. A lot of companies can’t actually afford it. It’s quite an expensive hobby, failing.’”
So there you have it -- failure is an expensive hobby and the few IT leaders left in organizations will be very highly valued, very highly skilled, and very important.
There’s more to the story and I’ll share what I’ve learned over the past few years helping companies cross the Cloud chasm and accelerating their digital transformation.
I gave several training courses on being a Tech Lead and found myself giving a number of book recommendations. Although books are no substitute for experiential learning and close feedback cycles, they are useful as ways of introducing some key skills developers rarely practice in their day-to-day tasks.Negotiation
A Tech Lead represents both the technical perspective to outside stakeholders, and often carries a business perspective back into the technical team. Conflict is inevitable and understanding how to negotiate to an optimal solution for two parties is a timeless skill.
Getting to Yes was one of my favourite books. It’s short and insightful. The book describes the different between Positional-based negotiation (typical) vs Interest-based negotiation.
Meetings. Meetings. Meetings. Three dreaded words that a developer doesn’t want and often can avoid. A Tech Lead often dreads the numerous meetings as well, but will be often expected to contribute. Most meetings will be poorly planned and facilitated, leading to even more drawn-out meetings. In my experience, when done well, meetings can be focused, short and fruitful when they are well-facilitated. Facilitation skills are also useful on a day-to-day basis when ad hoc meetings between team members occur, or when a particular topic needs to be discussed.
The more collaborative a team becomes, the more useful facilitation skills are to the Tech Lead as they blur into the background to all voices be heard.
The Skilled Facilitator (Schwartz) is the first book I recommend to new facilitators. I find the book easy to read and is comprehensive in its explanation about the role of the facilitator.
Facilitator’s Guide to Participatory Decision-Making (Kaner) is a more focused book, covering how to have group discussions, balance hearing all views and to converge into the best outcome.
Collaboration Explained (Tabaka) is written by an agile practitioner who I trust dearly. I have see her facilitate, and her wisdom is captured in this book that will be highly relevant to particularly agile teams.
With authority comes responsibility and the Tech Lead suddenly sees risks everywhere. Or worse, they don’t see any risks at all.
Waltzing with Bears (De Marco and Lister) is the timeless book that talks about risk management in the settings of software development. Although some of the examples may feel a bit outdated (death march projects), our industry still has plenty of them and the lessons are still relevant for today’s style of software development.
Unsurprisingly the book recommendations above are not only relevant to Tech Leads, but to anyone who may find themselves in a leadership role. There are plenty more skills and books to recommend, but these are a good starting set.
Hi Everyone. A Scrum Alliance colleague of mine mentioned that in a conversation with Jeff Sutherland (one of the authors of Scrum), Jeff suggested that the community could request and vote on a change to the Scrum Guide (the official description of Scrum) in order the add the values back to the guide. The values are normally listed as focus, commitment, courage, openness and respect. Please go and vote (and / or discuss) this on the Scrum Guides User Voice page. Voting is super easy – you just need to sign in with Facebook.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!
Book here: https://www.eventbrite.co.uk/e/agile-development-at-tesco-bank-tickets-13922136485
2. Reminder: 60% of the tickets have already sold out for Nancy V's Agile Hardware session next week.
Book here: https://www.eventbrite.co.uk/myevent?eid=13660303335