Developing on the Mac has generally been an awesome experience over the years especially with OS X and the UNIX underpinnings. The long pain point in this area is the lack of a solid supported package manager. It’s not in Apple’s DNA to worry about power users who actually use the terminal, and they’re unlikely to ever consider it important enough to delegate resources too. MacPorts and its hipster cousin Homebrew have been around for a while, but they’re always a bit rough around the edges, missing packages here and there, old versions, and sometimes they need extra tinkering just to install. In all it’s a most un-Mac like experience.
I don’t know that it will ever happen, but I know I’d support a Kickstarter that promised to maintain a Mac package manager like rpm or apt for OS X. I don’t care if they use Homebrew or Macports and just make it more robust, or build a new one from scratch. I’d just like a simple install of all those open source libraries. Yehuda Katz did a simple installer for Ruby and Rails on OS X a few years back via a Kickstarter, so I know there’s precedent and this would impact a lot more developers. Saving hassle is certainly worth some bucks for a kickstarter.
A collaboration by David Grabel and Mario Moreira
You’ve just been given a plum assignment, heading up a major new application development project. Congratulations! Your boss just got off the phone with a large off-shore contracting firm. At the labor prices they are quoting, we’ll save a fortune and come in under budget. He knows that you’ve been experimenting with virtual teams; it’s time to kick this into high gear and really cut our labor costs. DON’T DO IT!By the time you factor in the extra costs for travel, the high costs of the locally based support personnel (project managers, architects, etc.), the increased systems and telecommunications cost, the miscommunication caused by lack of face-to-face conversations, and the rewrites this will require, the cost savings will evaporate. They will never complete it on time and the missed revenue alone will eat up all of your savings.
There are good reasons to rely on virtual teams. Cost savings is not one of them. Real world constraints can make virtual teams unavoidable. Your company might have a liberal “work from home” policy. Your development centers could be scattered about a large campus, across the country or around the world. You may have a strong relationship with an off-shore development company that has delivered high quality software on time in the past. You might be partnering with a company from another state. All virtual teams are distributed, whether it’s a single member working from home or dozens of teams scattered around the world. Co-located teams will almost always be more efficient and effective than virtual or distributed teams. When virtual teams are unavoidable, the key to success is to Be Agile. If you follow the agile values and principles you can successfully deliver valuable working software, quickly, with high quality, even with virtual teams. Let us explore how the Agile values and principles can be put into action to help with virtual teams.
- Value people and interactions over processes and tools by enabling virtual and physical face-to-face conversations. If team members are in different time zones, encourage flexible hours and provide high quality video conferences for stand-ups and other ceremonies. Supplement the teams with collaboration tools. Bring the teams together periodically to learn each other’s business contexts, cultures, and individual needs. Virtual teams necessarily need to rely more on electronic tools like agile project managers and collaboration software. These tools help, but virtual teams need to nurture the interpersonal relationships that allow trust to develop. Trust within and across teams is vital to agile success.
- Value working software over comprehensive documentation by writing stories about the users experience and by delivering small increments quickly based on those stories. The traditional wisdom has been that virtual teams require very detailed requirements and design documents. These heavyweight artifacts don’t exist on agile projects. Very detailed requirements create the illusion of completeness and accuracy. All those details about what they system shall do obscure the problems we are trying to solve
- Value customer collaboration over contract negotiations by scheduling regular demos with customers to get their feedback and deepen the understanding of the business problems to be solved. This is more important than checking the boxes on a requirements document. This is a case where virtual meeting tools can bring remote teams and customers together even when they are physically apart.
The agile values and principles are the best guiding lights available today to make virtual teams work. If you have to use virtual teams, please consider using agile practices and staying true to the values and principles.
Before my team started development, the client started working on a “requirements document.” It’s full of statements like “The system shall allow the user to select a need by date” Now while each snippet can help provide information, the document as a whole is about impossible to digest in order to understand what we’re supposed to build. I’m going through the document and working with the client team to extract user stories.
As I’m working with the client, I am also trying to build the agile mindset within them. Agile isn’t just about following a different process. It’s about thinking about what you’re doing, inspecting and adapting as you go. In order to do this effectively, you need to know the why behind your actions. Why are we writing user stories instead of requirements documents? Why do we work in short iterations? Understanding this will help them become more agile, even after my team and I leave...and maybe they'll no longer be writing "the system shall..."
Here are the slides for an interactive workshop Olaf Lewitz and I presented at Agile 2015. Reinventing Organizations for Enterprise Agility from Michael Sahota Description We present an alternative view to fitting agile into larger organisations to achieve the goal of Enterprise Agility. Inspired by Fred Laloux’ book “Reinventing Organisations”, we offer a coherent and […]
One of the discussion topics I’ve seen raised again and again in agile circles is about absolute vs relative estimation. The theory goes that human beings find it difficult to estimate in absolute numbers like estimating the height of a building in metres, but find it easy to do relative estimations like estimating that a coconut is four times as big as a guava. And this is the reason why estimating a story in story points (relative estimate) is superior to estimating a story in hours (supposedly an absolute estimate). This theory finds it’s way into every agile discussion on estimation, as well as many trainings.
And yet, this theory, is completely wrong! (At this point I’ll admit that I’ve myself said this before)There is no such thing as “absolute estimation”
Let us first get one thing out of the way: There is no such thing as absolute estimation.
ALL common measurements-like measuring the height of a building for example-is a relative measurement. After all, a metre is just a standard baseline defined by the International Bureau of Weights and Measures. If you call something as 5 metres long, it just means that it is 5 times as big as this standard baseline. Someone else might say that it is 16 feet long, and they get a different number because they use a different baseline. So measuring distance in feet or metres is just a relative estimate of multiples to a reference value.
It is no different from setting a reference story as 1 story point and measuring multiples against that reference.
The same goes for other types of measurements, like time for instance. Someone just decided to divide a day into 24 pieces and defined a reference value of 1 hour. When we say something will take 5 hours, we just mean it is 5 times as long as this reference. It is a relative estimate, just like story points.
So it is completely wrong to say that story pointing is better because humans are better at relative estimating, because estimating in hours is ALSO a form of relative estimating.Comparing vs Estimating
One aspect of the first statement is true: it IS easier to say that a coconut is four times as big as a guava, than it is to estimate a building height in metres. The reason is not anything to do with relative or absolute estimating (remember that BOTH are relative estimates), but with how well humans can compare things. We are good at comparing objects that are similar in measure, but bad at comparing things that are of much bigger or smaller scale. As an example, it is easy to use a guava as a reference and say that the coconut is about four times bigger. But if I were to ask how big the Earth is relative to a guava, then most would be wildly off the mark (by wildly I mean more than a trillion times off the mark). However, if I were to ask how big the Earth is relative to Mars, folks would be reasonably close to the answer.Putting this to use
Alright, that’s a lot of theory, but is it of any use? Fortunately it is!
Here is the anti-pattern: I’ve seen teams define a tiny 1 point story as a reference baseline and then try to size larger features or epics relative to this tiny story. It just doesn’t work because we are no good at sizing a big thing using a tiny thing as a reference. And then the team wonders why the superior “relative estimation” is not working.
If you’ve read this far, the fix should be obvious: Create a reference story at every scale. You should be having a reference 1 point story for tiny fixes. A reference 10 point story (13 points if your team rigidly sticks to fibonacci) for new features. A reference 100 point story for larger epics, and so on. Then compare your stories against the appropriate reference story.
So, to get back to the hours vs story point debate, does this mean that if we could create reference stories in hours, like saying that this is a 1 hour story, that one is a 10 hour story and so on, and then comparing stories against the reference, then an hourly scale would work just as well as story points? I’ll leave that question open to address in the next blog post.
In v.3.7.2 we introduced a new Relations type called ‘Duplicate’. When on an entity view and you select any other entity to be added as a duplicate, it appears in the Outbound Relations section.
Starting with v.3.7.7 you can now merge duplicate Requests or Bugs. You’ll notice a ‘Duplicate’ list on the view, directly below the entity state. When you click the ‘Merge’ button a few things happen. First, attachments from any duplicates that are not in the final state are added to the primary entity and then any descriptions and comments will be copied as a comment tree to the primary entity. Finally, all the duplicates will then be moved to their final state, be tagged ‘merged’ and a comment with a link to a primary entity will be added. If you merge Requests, then all unique requester names will be added to a primary entity.
Now if you use CSV import for adding new or updating existing Targetprocess entities then assigned Team is taken into account. It means you may do a batch update of a Team for a set of entities.Fixed Bugs
- Fixed: Comet update event (if out-of-proc) refers to a Comet server instead of a TP application server
- Fixed: Time records absent if a Role is not set for at least one time record
- Fixed: unable to add a new tab to the Requester view
- Fixed: top quick add context is not updated if current context is changed from the top team/project selector
- Fixed comet exception “Only ITestRunItemDto instances are allowed here”
- Fixed: invalid slice definition exception if visual encoding rule is applied and all cards are deselected in board settings
- Fixed: The Visual Encoding tab for View Setup is broken in IE10
Agile 2015 was the week of Aug 3-7 this year. It was a great week. Here are the links to my interviews and talks.
Interview with Dave Prior. We spoke about agile programs, continuous planning, and how you might use certifications. I made a little joke about measurement.
Interview with Paul DuPuy of SolutionsIQ. We also spoke about agile programs. Paul had some interesting questions, one of which I was not prepared for. That’s okay. I answered it anyway.
The slides from Scaling Agile Projects to Programs: Networks of Autonomy, Collaboration and Exploration. At some point, the Agile Alliance will post the video of this on their site.
The slides from my workshop Agile Hiring: It’s a Team Sport. Because it was a workshop, there are built-in activities. You can try these where you work.
My pecha kucha (it was part of the lightning talks) of Living an Agile Life.
I hope you enjoy these. I had a great time at the conference.
[[ This is a content summary only. Visit my website for full links, other content, and more! ]]
Ever seen a sucky demo? One that doesn’t start on time, with technology issues, too many people in the room, people on the phone not on mute, confusion over what stories will be demo’d and who will demo them? Let’s have no more sucky demos. Here are some thoughts on how to make that happen.Plan It!
Decide which stories need to be demo’d well in advance of the demo. Some teams decide this before or during sprint planning. Go a little further and specify the demo script in advance, sort of the Acceptance Criteria for the completed demo. Just add that to the story description. Make it part of story grooming and the story readiness criteria (i.e. a story can’t be taken into a sprint without demo requirements specified). During planning, put a sub-task on the story for doing the demo and assign it to someone at some point during the sprint. At the very latest, decide and publish the demo plan at least 24 hours in advance. The Product Owner (PO) should have a say in that decision.“Ok, we’ll get started in a few minutes… just waiting for a few more people to join.”
Start on time. Give no quarter. Find out how to turn off the announcement chimes (entry and exit chimes) and on-hold beeps in WebEx and GoToMeeting.
- In GoToMeeting on Mac, in the Audio pane, there is a drop-down button to turn this off. I’m told there are 3 dots in the Audio pane on Windows. Click that. It used to be an Edit button and may still be if you have an older version of GoToMeeting or GoToWebinar?
- I’ve read about how to do this in WebEx, but haven’t tried it. Check the audio settings.
Practice. Those doing the demo need to get exceptionally good with the tooling (Screen share, audio conference, video conference, projector/monitor, starting on time, muting, volume, changing presenter, etc.). Don’t wait for improvements to come with time. Be intentional. Have each person who will ever be involved in a demo watch the training video for presenters that are provided from gotomeeting or webex or whatever. Find such a video and have everyone watch it.
Have a GoToMeeting/WebEx kata. A Kata an exercise of scripted activities to do. Like a coding kata, have kata for everyone to practice using GoToMeeting/WebEx. They could do the practice with an intern, or together in pairs, especially in onshore/offshore pairs. It should cover give and accept presenter mode, share screen, share screen 2, stop sharing, share individual app, turn on mic, turn off mic, muting other people, turn volume up and down, set someone else as presenter, turn off entry/exit chimes, turn off on-hold beeps, etc.“Oh, uh, I don’t know why it did that. Wasn’t expecting that.”
Rehearse. Do a dry run. Don’t surprise the PO. Your PO should see working software before the demo.Faster Feedback
Another alternative is to have the tester/developer call for a live demo during the sprint as stories are finished. Just call the PO over and show ’em what you’ve got running.
This might not work if you have a large team or a large number of people on the PO Team or a large number of PO’s and BA’s that need to see the demo. To deal with that, maybe allocate daily demo time, kind of like PO office hours. Or only require that story’s one BA (instead of all the BAs and POs) see the demo.Asynchronous Demos
Record it. As an alternative to a long demo with everyone in the room on the last day of the sprint, consider having the developer and tester who did the story record their demo as they finish the story, then send out the link to the recording. This will get feedback from PO’s and BA’s earlier in the sprint. This will allow Product Support and new hires to watch demos later when it is more relevant to them. It will also allow people to only watch the demos they care about.
Recording will also allow the team to do it over if it doesn’t go well the 1st time they attempt to record it.
People can still ask questions, just offline. The only downside is that everyone can’t hear the questions that others ask, but you could post the recordings on yammer or confluence or somewhere so that Q&A can be done online.“…so now I’m going to show you… Hi. Who just joined?”
Sometimes there are too many people in the demo. Too many voices, too many side conversations. Some people don’t seem interested. Some people join the conference call late.
Consider excluding non-essential people. Make the focus of the demo to suit the needs of the BA and PO only. Disregard the secondary purpose of the demo, which often is for other people to know about recent changes. Another option to consider would be to record the demos or to have separate demos for the secondary purpose (to narrow the audience and improve focus).Rock the House
A great end of sprint demo will turn people on to agile and increase support for your team. Do them well, or don’t do them at all.
I recently wrote some code that was similar to this (although much more complex and deeply structured – but this gets the point across).
In this example, the FiltersController attaches to an event on the Postal.js channel every time a new controller is created.
Having global channels access via name is great. You can use this to get multiple parts of your app to communicate, without having to pass around broker instances. Just ask for the channel by name, and you have the same one everywhere you ask for it.
But adding a callback method to the global channel and never cleaning it up is dangerous. Once you add that callback, the global channel will hang on to it even if the FiltersController instance is garbage collected.Zombies
The global channel might seem ok off-hand… but the next time you create a new FiltersController instance, you add yet another callback as well. Trigger the “add” event and you will have 2 or more callbacks firing – some of which will be looking for objects that may not be available or may be in a state that cause a myriad of potential problems.
The result is a zombie object with strange errors like the one shown here. The worst part about these errors is that the code looks fine and runs fine the first time. It takes two or more instances of the object for the problem to show itself – something that often doesn’t happen until a long time later when it’s not obvious what the cause is.
The easy fix is to ensure you clean up your callbacks on the global channel. But that “easy” fix isn’t always easy – and it isn’t always the best way to fix the problem.Local Broker Instance
There’s nothing wrong with global broker channels, if you remember to clean up your handlers. But I find that local broker instances can often be useful for situations where I know the limited scope of a given channel.
In the case of the FiltersController, I replaced my global channel with a local broker instance (using Backbone.wreqr in this case):
There are very few changes to this code, but the changes are important.
Now, when a new FilterController is created a local broker instance is created with it. This gives the broker a very limited scope. I can’t access this broker from any other code in any other part of the system. There is no global registry of broker channels – just this one broker instance.
That one change was enough to get rid of the zombies I was seeing.
When the FilterController was garbage collected, the broker went along with it. The next controller to be created used a new broker, preventing the zombies from occurring.Know The Scope Of Your Broker
As I said before, there is nothing inherently wrong with global channels and channel-based brokers. I use Postal.js a lot and I really like it. The key is understanding the scope in which your brokers need to be available.
If you’re dealing with a very broad scope of events, commands and messages, then a global channel is probably a good way to go. If you have a very limited scope for a broker, and you need that broker to go away when the limited scope is shut down, use a local broker instance.
Keep your global channels global, and create local brokers for local needs.
Of course, nothing is that simple or cut and dry. If you do decide to use a global channel for your message broker, be sure to clean up the message handlers.
“The questions that we must ask ourselves, and that our historians and our children will ask of us, are these: How will what we create compare with what we inherited? Will we add to our tradition or will we subtract from it? Will we enrich it or will we deplete it?”
― Leon Wieseltier
Digital transformation is all around us.
And we are all digital employees according to Gartner.
In the article, Gartner Says Every Employee Is a Digital Employee, Gartner says that the IT function no longer holds a monopoly on IT.A Greater Degree of Digital Dexterity
According to Gartner, employees are creating increasing digital dexterity from the devices and apps they use, to participating in sharing economies.
"'Today's employees possess a greater degree of digital dexterity,' said Matt Cain, research vice president at Gartner. 'They operate their own wireless networks at home, attach and manage various devices, and use apps and Web services in almost every facet of their personal lives. They participate in sharing economies for transport, lodging and more.'"Workers are Streamlining Their Work Life
More employees are using technology to simplify, streamline, and scale their work.
"This results in unprecedented numbers of workers who enjoy using technology and recognize the relevance of digitalization to a wide range of business models. They also routinely apply their own technology and technological knowledge to streamline their work life."3 Ways to Exploit Digital Dexterity
According to Gartner, there are 3 Ways the IT organization should exploit employees' digital dexterity:
- Implement a digital workplace strategy
- Embrace shadow IT
- Use a bimodal approach
While it’s happening organically, IT can also help shape the digital workplace experience. Implement a strategy that helps workers use computing resources in a more friction free way and that play better with their pains, needs, and desired outcomes.
“Making computing resources more accessible in ways that match employees' preferences will foster engagement by providing feelings of empowerment and ownership. The digital workplace strategy should therefore complement HR initiatives by addressing and improving factors such as workplace culture, autonomous decision making, work-life balance, recognition of contributions and personal growth opportunities.”2. Embrace shadow IT
Treat shadow IT as a first class citizen. IT should partner with the business to help the business realize it’s potential, and to help workers make the most of the available IT resources.
“Rather than try to fight the tide, the IT organization should develop a framework that outlines when it is appropriate for business units and individuals to use their own technology solutions and when IT should take the lead. IT should position itself as a business partner and consultant that does not control all technology decisions in the business.”3. Use a bimodal approach
Traditional IT is slow. It’s heavy in governance, standards, and procedures. It addresses risk by reducing flexibility. Meanwhile, the world is changing fast. Business needs to keep up. Business needs fast IT.
So what’s the solution?
Bimodal IT. Bimodal IT separates the fast demands of digital business from the slow/risk-averse methods of traditional IT.
“Bimodal IT separates the risk-averse and ‘slow’ methods of traditional IT from the fast-paced demands of digital business, which is underpinned by the digital workplace. This dual mode of operation is essential to satisfy the ever-increasing demands of digitally savvy business units and employees, while ensuring that critical IT infrastructure and services remain stable and uncompromised.”
Everyone has technology at their fingertips. Every worker has the chance to re-imagine their work in a Mobile-First, Cloud-First world.
With infinite compute, infinite capacity, global reach, and real-time insights available to you, how could you evolve your job?
You can evolve your digital work life right under your feet.You Might Also Like
“Courage doesn't always roar. Sometimes courage is the little voice at the end of the day that says I'll try again tomorrow.” -- Mary Anne Radmacher
Imagine if you could wake up productive, where each day is a fresh start. As you take in your morning breath, you notice your mind is calm and clear.
You feel strong and well rested.
Before you start your day, you picture in your mind three simple scenes of the day ahead:
In the morning, you see yourself complete a draft you’ve been working on.
In the afternoon, you see yourself land your idea and win over your peers in a key meeting.
In the evening, you see yourself enjoying some quiet time as you sit down and explore your latest adventures in learning.
With an exciting day ahead, and a chance to rise and shine, you feel the day gently pull you forward with anticipation.
You know you’ll be tested, and you know some things won’t work out as planned. But you also know that you will learn and improve from every setback. You know that each challenge you face will be a leadership moment or a learning opportunity. Your challenges make you stronger.
And you also know that you will be spending as much time in your strengths as you can, and that helps keeps you strong, all day long.
You motivate yourself from the inside out by focusing on your vision for today and your values. You value achievement. You value learning. You value collaboration. You value excellence. You value empowerment. And you know that throughout the day, you will have every chance to apply your skills to do more, to achieve more, and to be more.
Each task, or each challenge, is also a chance to learn more. From yourself, and from everyone all around you. And this is how you never stop learning.
You may not like some of the tasks before you, but you like the chance to master your craft. And you enjoy the learning. And you love how you get better. With each task on your To-Do list for today, you experiment and explore ways to do things better, faster, and easier.
Like a productive artist, you find ways to add unique value. You add your personal twist to everything you do. Your twist comes from your unique experience, seeing what others can’t see from your unique vantage point, and applying your unique strengths.
And that’s how you do more art. Your art. And as you do your art, you feel yourself come alive. You feel your soul sing, as you operate at a higher level. As you find your flow and realize your potential, your inner-wisdom winks in an approving way. Like a garden in full bloom on a warm Summer’s day, you are living your arête.
As your work day comes to an end, you pause to reflect on your three achievements, your three wins, for the day. You appreciate the way you leaned in on the tough stuff. You surprised yourself in how you handled some of your most frustrating moments. And you learned a new way to do your most challenging task. You take note of the favorite parts of your day, and your attitude of gratitude feels you with a sense of accomplishment, and a sense of fulfillment.
Fresh and ready for anything, you head for home.
Try 30 Days of Getting Results. It’s free. Surprise yourself with what you’re capable of.