Skip to content

Feed aggregator

Insights from a Kanban Board

AvailAgility - Karl Scotland - 4 hours 37 min ago

Donkey DerbyI was working with a team this week, part of which involved reviewing their kanban board and discussing how it was evolving and what they were learning. There was one aspect in particular which generated a number of insights, and is a good example of how visualising work can help make discoveries that you might not otherwise unearth.

The board had a “On Hold” section, where post-its were collected for work on which some time had been spent, but which was not actively being progressed or had any expectation to be progressed, and which wasn’t blocked in any way. Quite a lot of work had built up in “On Hold”, which made it an obvious talking point, so we explored what that work was, and why it was there. These are the things we learnt:

  1. Some of the work wasn’t really “On Hold”, but were really requests which had been “Assessed” (the first stage in the workflow) and deemed valid and important, but not urgent enough to schedule imminently. This led to a discussion about commitment points, and a better understanding of what the backlog and scheduling policies were. In this case, items were not really “On Hold”, but had been put back on the backlog. In addition, a cadence of cleaning the backlog was created to remove requests that were no longer valid or important.
  2. Some of the work was “On Hold” because while it was valid and important, the urgency was unknown. It was an “Intangible” class of service. As a result it was always de-prioritised in favour of work where the urgency was clearer. For example work to mitigate a security risk wasn’t going to be urgent enough until the risk turned into a genuine issue which needed resolving. To avoid these items building up, and generating even greater risk, a “Donkey Derby” lane was created as a converse of their “Fast Track” lane. Work in this lane would progress more slowly, but at least there would always be at least one “Intangible” items in process.
  3. A very few items were genuinely “On-Hold”, but they were lost amidst the noise of all the other tokens. Thus any discussion about what to do, or what could be learned, was being lost.

In summary, by visualising the “On Hold” work (however imperfect it was), and creating a shared understanding, the team were able to improve their knowledge creation workflow, better manage their risk and increase their ability to learn from their work.

Categories: Blogs

Kicking off the new year with SAFe in Brussels and London

Agile Product Owner - 5 hours 1 min ago

In January, I’ll be speaking at two events in London and Brussels:

Scaling Agile for the Enterprise Consortium in Belgium on January 22

In Belgium, I’ll deliver the keynote where I’ll focus on the Principles of Lean-Agile Leadership which provides a roadmap for managers and executives who are committed to gaining the knowledge and skills necessary to lead the next generation of Lean-Agile software enterprises.

Rally’s Agile on the Rocks in London on January 23

In London, I’ll delve into how improving return on investment in IT via agility at scale requires a new approach to portfolio and program management. I’ll cover:

  • Lean-Agile practices of SAFe Program Portfolio Management
  • The value of training and education in support of this new way of working
  • How to leverage expertise from those who’ve helped others adopt SAFe

Both of these will be great events for people in any stage of a Lean-Agile transformation.

Hope to see you there.

—Dean

Agile on the RocksAgile Consortium

Categories: Blogs

Why are you doing Scrum?

Scrum Breakfast - 5 hours 49 min ago
I am often asked questions like, "What do I do in Scrum when my team is spread across three locations?" My answer is usually something like, "you will suck." "Don't tell me that! That's insulting! I have to do that." At this point, I smile to myself and think, "that may be true, but you will still suck."

Why do I have conversations like this?

Last week, a got a question about electronic task boards. I could smell another one of these 'yes, but' discussion starting, so I chose to answer the question with a question: Why are you doing Scrum? I drew this picture on a flip chart and invited the participants to put dots on the location corresponding to their (organization's) goals:


Most dots were to the left of middle, the low performance choice, which explains why people did not like the high performance answer.

Scrum is based on the patterns of the 95th percentile of project performance, i.e. those awesome teams that are 3 to 10 times more effective than average. Those patterns are probably the same patterns as you experienced in your own best projects!

So why are you doing Scrum?






Categories: Blogs

Swift self reference in inner closure

Xebia Blog - 9 hours 25 min ago

We all pretty much know how to safely use self within a Swift closure. But have you ever tried to use self inside a closure that's inside another closure? There is a big chance that the Swift compiler crashed (Xcode 6.1.1) without giving you an error in the editor and without any error message. So how can you solve this problem?

The basic working closure

Before we dive into the problem and solution, let's first have a look at a working code sample that only uses a single closure. We can create a simple Swift Playground to run it and validate that it works.

class Runner {
    var closures: [() -> ()] = []

    func doSomethingAsync(completion: () -> ()) {
        closures = [completion]
        completion()
    }
}

class Playground {

    let runner = Runner()

    func works() {
        runner.doSomethingAsync { [weak self] in
            self?.printMessage("This works") ?? ()
        }
    }

    func printMessage(message: String) {
        println(message)
    }

    deinit {
        println("Deinit")
    }

}

struct Tester {
    var playground: Playground? = Playground()
}

var tester: Tester? = Tester()
tester?.playground?.works()
tester?.playground = nil

The doSomethingAsync method takes a closure without arguments and has return type Void. This method doesn't really do anything, but imagine it would load data from a server and then call the completion closure once it's done loading. It does however create a strong reference to the closure by adding it to the closures array. That means we are only allowed to use a weak reference of self within our closure. Otherwise the Runner would keep a strong reference to the Playground instance and neither would ever be deallocated.

Luckily all is fine and the "This works" message is printed in our playground output. Also a "Deinit" message is printed. The Tester construction is used to make sure that the playground will actually deallocate it.

The failing situation

Let's make things slightly more complex. When our first async call is finished and calls our completion closure, we want to load something more and therefore need to create another closure within the outer closure. We add the method below to our Playground class. Keep in mind that the first closure doesn't have [weak self] since we only reference self in the inner closure.

func doesntWork() {
    weak var weakRunner = runner
    runner.doSomethingAsync {

        // do some stuff for which we don't need self

        weakRunner?.doSomethingAsync { [weak self] in
            self?.printMessage("This doesn't work") ?? ()
        } ?? ()
    }
}

Just adding it already makes the compiler crash, without giving us an error in the editor. We don't even need to run it.

Screen Shot 2014-12-19 at 10.30.59

It gives us the following message:

Communication with the playground service was interrupted unexpectedly.
The playground service "com.apple.dt.Xcode.Playground" may have generated a crash log.

And when you have such code in your normal project, the editor also doesn't give an error, but the build will fail with a Swift Compiler Error without clear message of what's wrong:
Command /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/swiftc failed with exit code 1

The solution

So how can we work around this problem. Quite simple actually. We simply need to move the [weak self] to the most outer closure.

func doesWork() {
    weak var weakRunner = runner
    runner.doSomethingAsync { [weak self] in

        weakRunner?.doSomethingAsync {
            self?.printMessage("This now works again") ?? ()
        } ?? ()
    }
}

This does mean that it's possible that within the outer closure, self is not nil and in the inner closure it is nil. So don't write code like this:

    runner.doSomethingAsync { [weak self] in

        if self != nil {
            self!.printMessage("This is fine, self is not nil")

            weakRunner?.doSomethingAsync {
                self!.printMessage("This is not good, self could be nil now")
            } ?? ()
        }
    }

There is one more scenario you should be aware of. If you use an if let construction to safely unwrap self, you could create a strong reference again to self. The following sample illustrates this and will create a reference cycle since our runner will create a strong reference to the Playground instance because of the inner closure.

    runner.doSomethingAsync { [weak self] in

        if let this = self {

            weakRunner?.doSomethingAsync {
                this.printMessage("Captures a strong reference to self")
            } ?? ()
        }
    }

Also this is solved easily by including a weak reference to the instance again, now called this.

runner.doSomethingAsync { [weak self] in

    if let this = self {

        weakRunner?.doSomethingAsync { [weak this] in
            this?.printMessage("We're good again") ?? ()
        } ?? ()
    }
}
Conclusion

Most people working with Swift know that there are still quite a few bugs in it. In this case, Xcode should give us an error in the editor. If your editor doesn't complain, but your Swift compiler fails, look for closures like this and correct it. Always be safe and use [weak self] references within closures.

Categories: Companies

Partnerships & Possibilities, Episode 4, Season 6: Virtual Teams, Real Challenges

Partnerships & Possibilities: A Podcast on Leadership in Organizations
EPISODE 3: THE DIFFERENT FACES OF LEADERSHIP

Photo Credit: martinhoward via Compfight cc

[Introduction] FutureWorks is a virtual team.

[01:00] In HBR’s newest issue, “Getting Virtual Teams Right” by Keith Ferrazzi.

[03:00] You can model three tiers of team members – core, operational, and outer.

[05:45] Calculate your team’s virtual distance – factors that exacerbate the challenges for a given team.

[09:00] Operational distance as opposed to Physical distance.

[10:00] Affinity distance.

[13:00] How many managers stop to think: “How I recruit, assemble, and construct this team will have a big impact on the outcomes I will get from them”?

[16:30] The moment “us” and “them” begins to form on a team, trust and therefore performance, erodes.

[18:40] When management begins to consider putting together cross-functional teams, it is worthwhile to pass out copies of Ferrazi’s article to everyone, and ask – “Have we considered all these factors?”

Harvard Business Review: Getting Virtual Teams Right

Agile Software Development With Distributed Teams by Jutta Eckstein
The Year Without Pants by Scott Berkun

Categories: Blogs

Agile In Action with Cloud Computing

Danube - Thu, 12/18/2014 - 20:00

Agile and Cloud computing are how software applications are delivered today. These trends are the result of advances in technology, ranging from increased processing power (which made virtualization a reality), and increased sophistication of storage area networks (which made storage seamlessly scalable), ubiquitous high-bandwidth network access, and the increased security and reliability of the Internet.

Agile development processes optimize the opportunity provided by cloud computing by carrying out software releases iteratively and getting user feedback more frequently. With agile development, the application is constantly subject to the reality check of actual users putting it through its paces. As a result, developers are less likely to get ahead of themselves by guessing what people will want. Nor are programming teams forced to estimate what they can deliver months in advance—an unattainable feat. Instead, R&D is more likely to build features people actually want. And because developers are looking ahead for weeks, not months, major new releases are far more likely to be delivered on time. Developers using this methodology call the process “continuous improvement.” For the organizations that have made this process work for them, there is no turning back.

But for much of its history, agile development was missing a crucial component: an ALM software development platform that supports, rather than thwarts, the rapid development cycles that make the methodology work. In traditional software environments which lack such a platform, new software distribution is an ordeal that requires patches, re-installation, and help from the support team. In such an environment, months, or even years are needed to get a new distribution into the hands of users. Incorporating their feedback into the next release then requires comparable time.

It is here that cloud computing makes a substantial difference. Cloud computing eliminates the cumbersome distribution requirements that can bring agile development to a crawl. There are no patches to distribute, and no reinstallations are needed. With cloud computing, new distributions are installed on hosted servers and made available to users immediately. As a result, it’s possible that the application you run today was modified just the night before.

Agile Methodology

Agile methodology refers to a disciplined project management process encouraging frequent inspection and adaptation. In early stages the Agile methodology approaches of software development tended to be slow, bureaucratic and inconsistent creating the need for a more adaptive method of software development. Agile methodology encourages teamwork, self-organization, and accountability. Most agile development teams comprise 5-9 employees and a single customer representative that work in a single open office to promote teamwork and cooperation.

Core Principles: 

  • Working software delivered frequently to customers
  • Software is a measure of progress
  • Late changes are welcome
  • Constant cooperation between business people and developers
  • Simplicity
  • Self-organizing teams
  • Adaptability

The Emergence of Agile Development

Out of necessity, development teams began shifting to frequent releases. At first, these iterative methods went with small cycles, but remained with a fixed schedule ahead of time (i.e. fixed budget, strict plan, and predetermined feature sets). So instead of the one major release, several minor releases would be scheduled.

This concept would be taken a step further: Iterative releases, with no fixed plan! Here, each release adds a bit of value, allowing for better decisions as to what features would be included next. Development now works in small cycles – planning and designing only far enough ahead to keep the flow working. With this increased flexibility, the burden of excessive formal documentation was greatly alleviated. Now testing is incorporated into each step of the process, not just at the end of each release.

Cloud Computing: An Agile Approach in IT

Cloud is not a single product, but rather a way to provide IT services. Learning how to securely virtualize IT assets into consolidated, easy to manage pool of servers and storage resources that can be provisioned as needed to support a wide range of applications and data types from a single, integrated infrastructure that is secure, reliable, scalable, cost-effective and agile in the face of changing demands.

Agile Development in Cloud

Advances in technologies such as virtualization, storage, and high-speed network access, as well as a growing comfort with Internet security and reliability, have led to increasing adoption of Cloud Computing. Cloud Service simply means the types of services can be provided to customers. Different models apply to different kinds of requirements, and can achieve different business objectives. A simple search and you may find internet hits with dozens of Cloud * as a Service, where * can be replaced by any one of the following: Desktop, Security, Data, Software, Platform, Infrastructure, IT, Testing, Hardware, Computing, Database, Storage, etc.

Service Models for Cloud:

  • SaaS (Software as a Service)
  • PaaS (Platform as a Service)
  • IaaS (Infrastructure as a Service)

SaaS: The Service Provider has very high administrative control on the application and is responsible for update, deployment, maintenance and security, while the consumer is free of any worries and hassles related to the service. The provider exercises final authority over the application. For Example: Service providers such as CollabNet TeamForge, Google, ZOHO and Amazon are all in SaaS and we are consumers for these products. Through the image below, we can understand behavior of Saas model for Cloud.

SaasModel Agile In Action with Cloud Computing Pic1: Saas Model for Cloud

PaaS: In plain English, PaaS is a platform where software can be developed, tested, and deployed, meaning the entire life cycle of software can be operated on a PaaS. This service model is dedicated to application developers, testers, deployers, and administrators. This service provides everything you need to develop a cloud SaaS application. A PaaS typically includes the development environment, programming languages, compilers, testing tools, and deployment mechanism. In some cases, like CollabNet CloudForge and Google Apps Engine (GAE), the developers may download the development environments and use them locally in the developer’s infrastructure, or, the developer may access tools in the provider’s infrastructure through a browser.

PaaSmodel Agile In Action with Cloud Computing

Pic2: PaaS Model for Cloud

IaaS: Cloud infrastructure services, also known as “infrastructure as a service” (IaaS), deliver computer infrastructure – typically a platform virtualization environment – as a service, along with raw (block) storage and networking. Rather than purchasing servers, software, data-center space or network equipment, clients instead buy those resources as a fully outsourced service. Suppliers typically bill such services on a utility computing basis, or the amount of resources consumed will typically reflect the level of activity. For Example: Farmville and Mafia Wars are two of the most popular Facebook games created by Zynga.com. They have more than 230 million monthly users running more than 12,000 servers on Amazon AWS. Amazon is the pioneer of IaaS.

IassSModel Agile In Action with Cloud Computing

 Pic3: IaaS Model for Cloud

Differences in SaaS, PaaS, and IaaS:

The difference between IaaS and the other two models of Cloud (SaaS and PaaS) is that the software that executes them is essentially yours. In practical terms, the model is based on the same principles of virtualization that we are all familiar with in the context of server partitioning or flexible storage. Rather than running a virtual image on a partition existing on a physical server in your data center, you spin it up on a virtual machine that you have created in the Cloud.

Antiquated software development processes such as the waterfall process, don’t exactly fit into this brave new world of Cloud and are increasingly being replaced by the Agile software development processes. According to a Gartner report titled “Predictions 2010: Agile and Cloud Impact Application Development Directions,” 80% of software development projects will utilize Agile development methods. Agile development methods – with their focus on frequent release and user feedback – align well with the Cloud computing paradigm, combining faster application delivery with collaborative, iterative development.

Next-Generation IT (Cloud Brokerage): Why We Need A Cloud Middleman, what Gartner has called a cloud services brokerage. Consumers and businesses have different needs. Gartner has said that cloud service brokerages now represent the biggest revenue opportunity in Cloud computing. As any software salesperson can tell you, ultimately it’s not about features and functionalities; it’s about changing how you do business. Cloud brokerages are already building the customer relationships that will make them the trusted partners for the duration of the public Cloud era. In the public Cloud-based model, three-year waterfall implementation plans have given way to three-month iterative plans. Experts are now valued not for their ability to select and install the right servers and storage devices, but instead for their knowledge and ability to navigate the Cloud vendor ecosystem. Core skills expected from service management providers are less about systems monitoring, and more about what it takes to keep applications running efficiently on cloud platforms.

What’s a cloud broker? Gartner defines it as “a type of cloud service provider that plays an intermediary role in cloud computing.” Perhaps better put, Cloud Brokers help you locate the best and most cost-effective Cloud provider for your needs.

If the user is looking for a storage-as-a-service provider, instead of going to the Cloud provider directly, they can use a broker for their requirements and find the best fit – in some cases this will be based on the best cost, availability, and performance.

There are two types of cloud brokers emerging: Passive and Active.

  • Passive Cloud Brokers provide information and assist you in finding the right cloud-based solution. They may gather user requirements, understand budgets, and then pick the best cloud providers for user needs and cost. They even assist the user in signing up. 
  • Active Cloud Brokers may provide dynamic access to different cloud providers based on cost and performance data, and they may use different cloud providers at different times based on what best serves their clients. They may even multiplex cloud providers so that clients use a single interface serviced by many providers.

How Cloud Computing Benefits an Organization

Cloud computing is the new wave of IT infrastructure that allows businesses to run their applications on a shared data center space. Unlike traditional licensed software, cloud technology brings in efficiency by eliminating the cumbersome processes related to software development, testing, installation and failovers.

The major advantages of Cloud computing includes:

  • No hardware or software is required for Cloud services
  • Easy integration with other enterprise solutions
  • Fast deployment, coupled with less probability of failovers
  • Highly customizable environment
  • Optimum utilization of in-house IT resources

How Agile and Cloud Computing Complement Each Other

Agile development methodologies and Cloud computing complement each other very well. Cloud services take pride in meeting user requirements rapidly; delivering applications whenever and to whatever extent they are needed. Agile methods give high credence to user collaboration in requirements discovery.

The agile system of software development aims to break down project requirements into small, achievable segments. This approach guarantees user feedback on every task of the project. Segments can be planned, developed and tested individually to maintain high quality standards with almost no bottlenecks.

Using agile development in conjunction with Cloud computing provides a highly interactive and collaborative environment. The moment developers finalize a feature, they can push it as a Cloud service; users can review it instantly and provide valuable feedback. Thus, a lengthy feedback cycle can be eliminated, reducing the probability of misstated or misunderstood requirements. This considerably curtails the time and efforts for the software development organization while increasing end user satisfaction.

Therefore, the major benefits of using agile software development in conjunction with the Cloud computing paradigm are:

  • Increased quality of application
  • Effective resource utilization
  • Reduced time to market
  • Cost savings

Working in agile methods with Cloud computing will enable organizations to strengthen their IT portfolio for better service delivery while lowering costs.

Scaling Agile – Enterprise Agility

In global organizations software developers work at multiple dispersed sites and use a wide array of agile and cloud development tools and processes. In many cases, even if the same technology and agile process is used, it can be deployed into the cloud and configured in different ways. Over time, enterprises end up with fractured development environments that include rampant amounts of “shadow IT”. This situation contributes to the inability of companies to follow best development practices, leverage software intellectual property, share knowledge, and identify problematic areas. This leads to increasingly higher costs of development, work duplication, slipping schedules, or worse, missed deadlines.

Today’s leading organizations seek to overcome this disparity and leverage their global teams and IP  by bringing  repeatable open, agile and collaborative development methods to global teams of developers – inside and outside of their company.  One such approach is CollabNet’s Blueprint for Enterprise Agility. 

blueprint for enterprise agility1 Agile In Action with Cloud Computing

Pic4: Blueprint for Enterprise Agility

Summary

Putting agile together with the Cloud dramatically accelerates an organization’s improvement pace. The working style of agile is tied to user involvement, thus drawing user’s right into the heart of the development process. Functionality is developed as the user wants it, how he wants it. As development cycle move along in cumulative steps (iterations), the features and benefits can be rationalized and re-prioritized as each project unfolds. There is no waste—either of time or money. And once everyone agrees that the application is ready, off it goes into the Cloud where everyone can start using it.

It’s no secret that agile in conjunction with Cloud computing is here to stay—offering the promise of everything from reduced complexity and unlimited scalability, to capacity on-demand. As Cloud computing continues to gain popularity, many enterprises are intrigued by the potential benefits it presents. The elasticity of the agile and Cloud partnership allows organizations to size their IT to fit their needs, rather than invest in equipment that they may not need. In uncertain environments and fast-changing markets, the Cloud’s dynamic provisioning lets IT organizations to concentrate on their day to day activities like, development, QA, software deliverables, and much more.

Agile development in the Cloud now provides organizations greater control over process innovation, giving them more competitive edge and opportunity across every vertical market.  Today’s leading companies have overcome their organizational disparity and leveraged their global teams and IP.  They have achieved overall enterprise agility and are deploying to clouds inside or outside of their company – by bringing repeatable open, agile and collaborative development methods to global teams of developers.  

Follow CollabNet on Twitter and LinkedIn for more insights from our industry experts.

 

The post Agile In Action with Cloud Computing appeared first on blogs.collab.net.

Categories: Companies

The Sweet Spot of Customer Demand Meets Microsoft Supply

J.D. Meier's Blog - Thu, 12/18/2014 - 19:10

Here’s a simple visual that I whiteboard when I lead workshops for business transformation.

image

The Sweet Spot is where customer “demand” meets Microsoft “supply.”

I’m not a fan of product pushers or product pushing.  I’m a fan of creating “pull.”

In order for customers to pull-through any product, platform, or service, you need to know the customer’s pains, needs, and desired outcomes.  Without customer empathy, you’re not relevant.

This is a simple visual, but a powerful one.  

When you have good representation of the voice of the customer, you can really identity problems worth solving.   It always comes down to pains, needs, opportunities, and desired outcomes.  In short, I always just say pains, needs, and desired outcomes so that people can remember it easily.

To make it real, we use scenarios to tell a simple story of a customer’s pain, needs, and desired outcomes.   We use our friends in the field working with customers to give us real stories of real pain.  

Here is an example Scenario Narrative where a company is struggling in creating products that its customers care about …

image

As you can see, the Current State is a pretty good story of pain, that a lot of business leaders and product owners can identify with.  For some, it’s all too real, because it is their story and they can see themselves in it.

In the Desired Future State, it’s a pretty good story of what success would look like.   It paints a pretty simple picture of what would be an ideal scenario …. a future possibility.

Here is an example of a Solution Storyboard, where we paint a simple picture of that Desired Future State, or more precisely, a Future Capability Vision.     It’s this Future Capability Vision that shows how, with the right capabilities, the customer can address their pains, needs, and desired outcomes.

image

The beauty of this approach is that it’s product and technology agnostic.   It’s all about building capabilities.

From there, with a  good understanding of the pains, needs, and desired outcomes, it’s super easy to overlay relevant products, technologies, consulting services, etc.

And then, rather than trying to do a product “push”, it becomes a product “pull” because it connects with customers in a very deep, very real, very relevant way.

Think “pull” not “push.”

You Might Also Like

Drive Business Transformation by Reenvisioning Operations

Drive Business Transformation by Reenvisioning Your Customer Experience

Dual-Speed IT Drives Business Transformation and Improves IT-Business Relationships

How Business Leaders are Building Digital Skills

How To Build a Roadmap for Your Digital Transformation

Categories: Blogs

Agile Conference Taiwan, Taipei City, Taiwan, March 27 2015

Scrum Expert - Thu, 12/18/2014 - 18:10
The Agile Conference Taiwan is a one-day event organized by the association Scrum Taiwan User Group p that discusses all aspects of Agile software development and project management with Scrum. The goals of the Agile Conference Taiwan is to increase understanding and usage of Agile methodology, exchange experiences in Agile transformation and practices, develop and grow the Taiwan Agile community. Web site: none Location for the 2014 conference: TABF, 62 Roosevelt Rd., Section 3, Taipei City, Taiwan
Categories: Communities

Manage Your Project Portfolio is Featured in Colombia’s Largest Business Newspaper

Johanna Rothman - Thu, 12/18/2014 - 17:11

Andy Hunt, the Pragmatic Bookshelf publisher, just sent me an email telling me that Manage Your Project Portfolio is featured in La República, Columbia’s “first and most important business newspaper.” That’s because getabstract liked it!  

la_república_20141204Okay, my book is below the fold. It’s in smaller print.

And, I have to say, I’m still pretty excited.

If your organization can’t decide which projects come first, second, third, whatever, or which features come first, second, third, whatever, you should get Manage Your Project Portfolio.

Categories: Blogs

Soft Skills

Bobtuse Bobservations - Bob MacNeal - Thu, 12/18/2014 - 16:39
Making software is a profoundly human activity. Successfully produced software is made: by teams.for people to use.Interpersonal communication and mindset are increasingly important for...

Bobtuse can be wildly informative
Categories: Blogs

Mathematics cannot prove the absence of bugs

Matteo Vaccari - Thu, 12/18/2014 - 16:08

Everyone is familiar with Edsger W. Dijkstra’s famous observation that “Program testing can be used to show the presence of bugs, but never to show their absence!” It seems to me that mathematics cannot prove the absence of bugs either.

Consider this simple line of code, that appears in some form in *every* business application:

database.server.address=10.1.2.3

This is a line of software. It’s an assignment of a value to a variable. And there is no mathematical way to prove that this line is correct. This line is correct only IF the given IP address is really the address of the database server that we require.

Not even TDD and unit testing can help to prove that it’s correct. What would a unit test look like?

assertEquals("10.1.2.3", 
    config.getProperty("database.server.address"));

This test is just repeating the contents of the configuration file. It will pass even if the address 10.1.2.3 is wrong.

So what is the *only* way to prove that this line of code is correct? You guessed it. You must run the application and see if it works. This test can be manual or automated, but still we need a *test* of the live system to make sure that that line of code is correct.

Categories: Blogs

Trust me… Agile just won’t work here…

Leading Agile - Mike Cottmeyer - Thu, 12/18/2014 - 15:18

I usually smile when I hear a statement like this: “Our culture is way too …” fill in the blank “Agile just won’t work here!”

Why do I smile?  I find that people are typically referring to a common belief that in order to be “agile” an organization’s culture needs to be one of “trust”.  The belief is that an organization should trust its people to:

(1) make the right decisions, and
(2) do their best to deliver products and services that will make the business succeed.

All good stuff, very good in fact. But, good or not, its a really steep hill to climb for an organization’s culture to go from (a) low-trust: managing projects for performance against their time, cost and scope commitments while focusing on departmental efficiencies to (b) high-trust: self-managed delivery systems that act responsibly within the available time and budget.

As we see in HBR’s article on organizational culture “Culture is powerfully shaped by incentives”. As a result, we need to figure out how to (a) build trust, and (b) change the incentives. Doing this is actually fairly straight-forward if you are working with your business’ leadership and solving for their issues. What are their issues?  In most organizations, their issues are how to make and meet commitments in a way that is within their defined budget.

Finding Better Ways to Meet Needs

Becoming agile isn’t about using this method or that method. It’s not even about trust. Its about creating a system that can respond to change in a way that creates safety for the business’ leadership by respecting their immediate needs.  So, instead of trying to just go out and be agile, I think we need to start with a business need and find ways to meet it while creating safety for the individuals involved. We need to create a roadmap to go from point a to b.

Most business leaders are desperate for better ways to deliver against their commitments while having the ability to adapt their plans along the way when things change. Most leaders are absolutely thrilled to trust their people; but, remember, to establish the trust we have to be willing to first make and meet commitments in a way that shows them we can be trusted.

Thoughts?

The post Trust me… Agile just won’t work here… appeared first on LeadingAgile.

Categories: Blogs

All the small things

Agile Zen - Wed, 12/17/2014 - 20:19

Over the past couple of weeks, we’ve released a few small changes:

1) Links no longer open in the same window.

2) The backlog can now be pinned open. If you click the thumbtack in the backlog, it will stay open until you unpin it for that project.

thumbtack

3) You can now have cards default to the top of a phase instead of the bottom. Your setting will be persisted by project.

add-to-top

Thanks!

Categories: Companies

‘Twas The Night Before Sprint Planning

Agile Management Blog - VersionOne - Wed, 12/17/2014 - 17:37

daniel gullo ABC consultingWe hope you enjoy this holiday poem on Sprint Planning. It was an early holiday gift to the Agile Management Blog from Daniel Gullo, owner/principal of Apple Brook Consulting. Thanks, Daniel!

‘Twas the night before Sprint Planning, and all through the Team
Not a member was worried about the upcoming theme.

The Stories were refined and the Backlog was set;
Poker had been played without a single bet.
Appropriately sized and estimates all sound;
Acceptance Criteria to establish firm ground.

The ScrumMaster and Product Owner had just finished a call,
To talk about ordering and a potential Sprint Goal.

The Retro had happened several days prior;
The Scrum Team had discussed how to move the bar higher.
Agreements were revised and the Definition of Done
Included more testing and other such fun.

The stakeholders were eager to see the new stuff:
“The product has value!! Perhaps we have enough??”

In the last Sprint Review, the Team had shone bright,
A shippable increment, a product in its own right.
Wouldn’t be long ‘til the Team would release,
Causing the customers’ delight to increase.

The CEO and the VPs were finally content,
The decision to be agile had caused no lament.

Developers are happy in practicing their trade
Testers are ecstatic they are no longer blamed.
And everyone has a chance to really collaborate
Without worrying about the build being late.

As dawn approached and meeting was nigh,
The Team members were up on an adrenaline high;
Excited to move forward and full of new hints,
The wonder of Scrum and working in Sprints.

“Is agile right for me?” you may be wondering,
As your organization continues with delivery blundering.
If your culture is ready to be focused on learning,
Agile will help you return to positive earning.

Blessings-

Daniel Gullo
CSC, CST

Get more info on sprint planning within VersionOne.

Categories: Companies

Beyond Coding

Agile Coaching - Rachel Davies - Wed, 12/17/2014 - 17:29

Software development on anything more than a pet projects is a collaborative activity. To enable a group of developers to make any headway, some details inevitably need to be hammered out together. However, you probably find that getting agreement within a group of opinionated developers can be difficult at the best of times. Most software developers haven't had training in "soft skills" and you may find it hard to know where to start when a difficult question needs to be thrashed out.

Here are some pointers to areas that you might want to explore beyond the realm of programming languages, methods and frameworks.

Facilitation is all about making conversations easier but even with a clear meeting purpose and agenda, you may find meetings can go around in circles without reaching consensus. To understand some approaches to making group decisions I recommend "Facilitator's Guide to Participatory Decision-Making" which introduces decision making rules. You can also get affordable hands-on training in facilitation from non-profit ICA-UK on Group Facilitation Methods.

Another thing you can do to help meeting participants is to create visible agendas and capture points being discussed concisely. If you want to build more confidence with writing neatly on flipcharts and whiteboards, seek out a course in graphic facilitation where you can pick up tips and practice with other budding facilitators. To improve how you illustrate system dynamics in group discussions, start to practice drawing Diagrams of Effects. Peter Senge's book "The Fifth Discipline" has a an excellent introduction to Systems Thinking and an handy set of system archetypes that you can use in different situations.

There's an old joke: What is the difference between a Methodologist and a Terrorist? You can negotiate with a terrorist! When discussions get heated, it's  handy to know a little bit about negotiation techniques. The Harvard Negotiation Project have put out a few paperbacks and I recommend "Getting Past No: Negotiating With Difficult People" by Fisher and Ury. Another easy read around building trust is "The Trusted Advisor" by Maister, Green and Galford.

Lastly remember that we can improve communication in our teams by starting with ourselves and how we express our own opinions. A good place to start is "Nonviolent Communication" by Marshall Rosenberg. An older book that's worth getting hold of to get a different perspective on the way you share feedback is "The Art of Giving Feedback" by Charles Seashore and Gerald Weinberg.

I hope these resources help you in situations where you need to go outside your comfort zone. Please do let me know if you have other recommended reading to share that goes beyond coding.

Categories: Blogs

MediatR hits 1.0

Jimmy Bogard - Wed, 12/17/2014 - 16:45

I’ve been using a project I wrote/borrowed/stole from a number of internal projects and existing libraries (thanks Matt) for well over a year now, and are releasing to 1.0. MediatR helps turn complex code into simplified request/response interactions, encapsulating queries, commands and notifications into a single, simple interface, collapsing complex controllers into simple pass-throughs to the real work being done:

public class ConferenceController : Controller
{
    private readonly IMediator _mediator;

    public ConferenceController(IMediator mediator)
    {
        _mediator = mediator;
    }

    public ActionResult Index(IndexQuery query)
    {
        var model = _mediator.Request(query);

        return View(model);
    }

    public ViewResult Show(ShowQuery query)
    {
        var model = _mediator.Request(query);

        return View(model);
    }

    public ActionResult Edit(EditQuery query)
    {
        var model = _mediator.Request(query);

        return View(model);
    }

    [HttpPost]
    public ActionResult Edit(ConferenceEditModel form)
    {
        var conf = _mediator.Send(form);

        return this.RedirectToActionJson(c => c.Show(new ShowQuery { EventName = conf.Name }), "Default");
    }
}

MediatR lets you send a request to a single handler:

var request = new ApproveInvoiceRequest {
   InvoiceId = invoiceID
};
ApproveInvoiceResponse response = mediator.Send(request);

Or do it asynchronously:

var request = new ApproveInvoiceRequest {
   InvoiceId = invoiceID
};
ApproveInvoiceResponse response = await mediator.SendAsync(request);

Or send a notification to a number of handlers:

var notification = new InvoiceApprovedEvent {
    InvoiceId = invoiceId
};
mediator.Publish(notification);

I’ve talked about the advantages to this pattern many times, and we use this pattern on nearly every project we encounter these days. The goal of MediatR was to create a small, unambitious implementation of the Mediator pattern, tied only to the Common Service Locator library for instantiating handlers and portable, so it works on just about every platform checkbox I could check, including Xamarin.

The GitHub repo has examples for plugging in all the major containers, and the wiki has documentation. Although the library uses Common Service Locator, it’s completely DI friendly too. Ultimately, the compositional tool is your container, and MediatR merely provides the mediation from message A to handler of A. Enjoy!

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

Categories: Blogs

The ROI of Multiple Small Releases

Agile Complexification Inverter - Wed, 12/17/2014 - 16:24
In a few minutes how do you explain the benefits of multiple incremental releases to someone new to this agile mindset?  I'm convinced that if I try to use words (which is typically the case when caught in a hallway conversation) or even words and a few quick sketches - I will not do justice to the complex concept.  Why?  Because this concept deals with multiple what if scenarios that play out in long timeframes with little feedback.

So needing to have this conversation today, I had the time to do a search for some help.  And I found this wonderful article and video with a voice over explanation.

Business Benefits of Software Release in Multiple Increments
And there is an interactive Wolfram graphic you can play with yourself.

http://demonstrations.wolfram.com/BusinessBenefitsOfReleasingSoftwareInMultipleIncrements/
Now with this link and the video explanation (done with a german accent I think, gives it real authority) - I can solve the problem of coming to that shared understanding.

Categories: Blogs

Working Agreements for Huge Meetings

Rally Agile Blog - Wed, 12/17/2014 - 15:00

Have you been in a meeting lately where people were focused on their laptops, interrupting each other, distracted, or otherwise behaving badly? In Jean Tabaka’s “Leading Collaborative Meetings” class, Jean talks about the importance of working agreements to create the safety that makes productive dialogue possible.

When I see people facilitating meetings around here, there are some common working agreements that show up often:

  • “One conversation at a time” helps people hear each other.  
  • “Electronics by exception” enables people to stay focused on the work rather than getting lost in their devices.  
  • “Start and end on time” is important if your discussions tend to run long.

But we also do a lot of large-scale meetings with 50, 100, or even 500 people working collaboratively on a plan.  And at scale, some of these agreements don’t work as well. “One Conversation at a time” doesn’t make sense much of the time. With 500 people, some are going to come and go.

So here are some of the agreements we’ve experimented with when more than 100 people are trying to agree on a plan, along with how we explain the working agreement to the group.

Aim for Good Enough

“With 300 people here, we’re trying to get to a reasonable degree of alignment. We’ll continue working on our plans throughout the release. When you’re engaging with the larger group, think about whether your issue needs to be discussed with everyone or whether it can be resolved with a smaller group. If we’re getting stuck, think about how a small group can work to bring back a recommendation to the larger group.”

Be Back on Time

“Large group meetings are expensive. It’s really important to be here on time so we don’t have hundreds of people waiting for you. This matters a lot when we come back together at 4 pm today, and when we start tomorrow morning.”

Raise Risks Early

“If you know of an important risk, raise it as early as you can. During the morning activity is your first chance; then during your breakouts you can also raise issues early. If you can resolve the issue today, that’s way better than making us stay late tomorrow.”

Leave if You Need to Do Other Work

“We have so many people here, there’s a good chance something will come up that requires some of us to shift our focus. If you do need to do other work, please step out completely so that the rest of the group can focus.”

We’ve had some success with these, especially when the “regular” working agreements have already become the cultural norm. What working agreements do you use in large-scale planning meetings?

Learn how to lead productive, enjoyable, effective meetings. Sign up for Jean Tabaka’s “Leading Collaborative Meetings” class today.

  Alex Pukinskis
Categories: Companies

confessions of a video game addict

Derick Bailey - new ThoughtStream - Wed, 12/17/2014 - 13:00

I LOVE video games! Love them. I’ve been playing them since I was 6 or 8, I think… and I’m still playing them nearly 30 years later.

When the game Destiny was released a few months ago? Picked it up on release day and played WWWAAAAAaaaayyy too much of it. Call Of Duty, Advanced Warfare? Same.

Sometimes felt guilty about how much I played. Sure, I’m all for relaxing and taking a break to recharge. But maybe I was playing too much? I mean, I was still getting the important things done… so… I don’t know.

But then, recently, my friend Matt Kremer got on twitter and started ranting and raving about how it’s not ok to feel guilty about taking time to relax… and he specifically mentioned video games… and I just had to reach out and ask him to write to you, here on my list, to let you know…

So here here is – Matt Kremer, a normal guy who enjoys business, marketing and programming. He has sweet blog at MattKremer.com and a podcast where he interviews budding and successful programmers gone entrepreneur. His side-project, Kobra.io, is a real-time collaborative code editor with built in video & voice chat.

—————–

[From Matt, to you]

I was going to send out an email to my followers with something along the lines of: “I’ve got something to admit to you guys,” “I feel bad about it, but…” or “I apologize that you haven’t heard from me in a while.” And then I stepped back and took a good hard look at myself.

And this is what I saw:

matt-kremer-gaming

The truth of the matter is I haven’t worked on my side-project in a month. In fact, I spent a good hour trying to draw that awesome picture instead of working on my side project. I’m pretty confident I’m almost as good as Derick.

So here’s the real deal: I’ve got a full-time job, a wife, a 10 month old son, a blog, a podcast and a side-project with paying customers.

Normally you hear from “internetprenuers” when they are in “always on mode.” You know what I’m talking about. It’s that beastmode where they are writing blog posts every single day, launching new features for their app, marketing the bejesus out of their products and talking about how if you just work harder and do what they do you can be a bazillionaire. A bazillionaire I tell you!

That’s an absolute load of crap.

I’ll tell you what I’ve spent the past 30 days doing: playing video games, spending time with my kid and drinking beers with my wife while we watch Netflix. And I feel like I should feel bad about that. But the truth of the matter is, I just dont. And neither should you.

Above anything else, your mental health is the most important thing you can work on right now. Your mental health is above that next dollar, that next feature, that next marketing push.

Since I’ve been playing a lot of video games, I’m going to put a little bit of video game metaphor in here for you, cool? Cool.

You, as a human being, only have 100 magic points (MP). It costs 50MP to build a new product, 25MP to launch it, 10MP to manage bugs, etc. Before you know it, you only have 5MP left. You may not be “burnt out” but you are at least tired.

Most of those internetprenuers you follow, they’re going to tell you to push through it. “Keep going! You could be the next big thing!”

Not me, I’m an advocate of one remedy: relaxation. That new video game that just came out? Go buy it, then beat it, then “100% it.” I found my old PSP-1000 in a drawer, dusted it off and picked up a copy of Madden ‘12. Because let’s be real, I want to watch Netflix AND play video games AT THE SAME TIME. That’s what heaven is, right?

But there is something really strange about this remedy. After you’ve beat that video game, all of the sudden you’re back up to 100MP. You’ve found a magic potion! A FRIGGIN’ MAGIC POTION. Your drive or “work ethic” will come back full force, and you’ll be able to get even more awesome magic stuff done.

So if you’re tired, if you just don’t feel like working today (or for a month), I’m prescribing you one treatment: relaxation. Take a vacation, play some video games, spend some time with your kid, have a romantic dinner, watch Netflix, drink some beers or whiskey. I’m not holding you up to any standards of grandeur, and you shouldn’t hold yourself to one either.

I hope you enjoy Matt’s story and admonition of why it’s not ok to feel guilty about taking a break. It certainly helped me get rid of the “I hope no one finds out” kind of sneaking around that I’ve been doing recently. And it’s also nice to know that I’m not the only one who does this, too!

So relax. Take a break. It’s ok. I promise.

– Derick

 

P.S. If you enjoy Matt’s writing as much as I do, and you’re not yet ready to take a break, we’ve got something special for you. Matt recently wrote an eBook on Building Software Products in a Weekend. I read it, and I was blown away! Matt has managed to reduced dozens of books that I have previously read, and experiences that I have had, in to a tremendously valuable book on starting a project or side project – and he’s making this treasure trove available to you at no charge! Just head over to MattKremer.com/dericksfans and get your copy. It is well worth it.

 

Categories: Blogs

Knowledge Sharing


SpiraTeam is a agile application lifecycle management (ALM) system designed specifically for methodologies such as scrum, XP and Kanban.